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()`
credits to @towolf
Icinga offers the user to enable or disable 'auto-refresh' with a
static preference.
But 'auto-refresh' is the default and our users often have dozens of
Icinga tabs open in their browser, which they are not looking at.
The background tabs lead to significant load on the database to to
repeated queries to keep the invisible UI fresh.
This change adds a visibility listener, which disables auto-refresh when the
page is not visible.
refs #2761
...foreign containers. Otherwise they will remain unusable. A better
solution might be tracking source containers, but that would involve
some more work
fixes#10263
