..if a renderHook discards an autorefresh. There is
unfortunately no way to distinguish between a renderHook
that really discards changes or one that applies them
on the DOM itself. If it's the first, this change
*shouldn't* hurt. If it's the latter, users should
benefit.
This has the same effect as a normal redirect. The benefit of it however
is that the server doesn't need to know what's being shown in the left
column. It just instructs the client to close the right and refresh the
left column. But still produces a new history state, it's a forward
navigation nonetheless.
It's still relatively slow as it forces a reflow in the
browser if there are many collapsibles in the view.
I didn't manage to identify the issue yet, but I left
a TODO at the location that's responsible for it.
The click event fires only after the mouse button is released, which
may happen on the outside, after the user tried to select something
and overrun accidentally. A close is then not desired as the user
may loose input. The mousedown event fires right when the button
is pressed and suffices on the outside of the modal.
Isn't the prettiest fix. I would have liked to completely
remove the target preparation from `getLinkTargetFor`.
But this is the easiest fix since it's only for modals
that preparation is not desired. It's also the most
compatible change.
Previously only the `#search` input wasn't disabled, now also
the new filter input isn't. This is required to re-focus the
input after submission as disabled elements loose focus.
This has previously not been an issue, as form submits seem to have
never targeted another url than their container's current one.
Though any form that did this, was pushed to history upon submit.
This happens now only for `GET` forms.
This header is only used in case the response includes
multipart content. It's meant to provide a new query
string that replaces the one of the targeted container
and the resulting change also replaces the current
history entry.
Previously any false value had this effect, though empty strings
were also discarded due to this. However, in case an empty string
is the content in the first place, the content must be updated.
`utils.parseParams()` now returns an array instead of an object.
This may require some changes in modules using this directly or
by `utils.parseUrl().params`
refs #4056
Though IDs should be unique across the whole page, focusElement() must
not fail if there is the same anchor in the left and right column.
focusElement() now also respects the container when searching the
element to focus by ID.
Before, we only had pushCurrentState() to add a new URL to the history
stack. But some actions, e.g. "load more" in history views require to
replace the current state instead of pushing. This is what
replaceCurrentState() supports now.
The `load` event is not really only fired *after all shared resources are loaded*.
Just Chromium ensures this event is fired only after `ready` and `DOMContentLoaded`.
FF, IE and Safari don't so we need our own post-init event: `icinga-init`
`beforerender` is already too late. Module initialization
done using an event handler is wrong anyway. It's some
kind of bootstrapping after all and should be performed
by parts of the code which is directly responsible for
DOM content handling of modules. (i.e. loader.js)
This change though introduces a side-effect which was
not the case previously: Nested `.container` elements
trigger `rendered` events now. I've introduced this to
ensure we're also lazy loading modules and let them
handle their `rendered` events right after a redirect
which rerendered the layout. (Only `#layout` got a
`rendered` event then prior to this change)
Cleans up how our JS initializes module javascript. Previously the `rendered`
event only got fired upon page load if a module got loaded as well. This is
now decoupled and `rendered` events fire for all containers and the entire
layout upon page load.
Notable changes:
* A `load` event initializes modules and triggers `rendered` on `.container` and `#layout` elements
* Module javascript (module.js) is still lazy loaded but with a `beforerender` event, not `rendered`
* Previously `#layout` received a `rendered` event during bootstrapping, this is not the case anymore
* Initial search value preservation now got its own handler `events.onRenderedMenu()`
* Initial dashlet loading now git its own handler `events.loadDashlets()`
Johannes Meyer
Alexander A. Klimov
Yonas Habteab
nmartini
Eric Lippmann
ValeDaRold
Florian Strohmaier