Instead of grid update run a full update, after keeping tab in the background for too long some alert groups are kept in the DOM where they should be purged. Chrome does some really complex background tab throttling, interwebz states that after >=10s in the background a tab can only use 1% of the cpu. Future code might need to use Web Workers API, assuming other vendors will use it too (https://arstechnica.com/information-technology/2017/03/chrome-57-background-tab-suspension-download/). For now let's just reload alerts when user switches to a previously background tab after more than a single refresh cycle, this will ensure that there's no dead alerts presents since that can be confusing
Fixes#104
@status filter was added to the master branch to support new status key from Alertmanager >=0.6.1
status ended up being nested in Alertmanager (it was added to solve AM issue 609 and that was a long PR with lots of changes), current unsee implementation ended being slightly off with how Alertmanager is naming this, it should actually be @state rather than @status.
When silence form is ready we should generate initial JSON preview, so when user clicks to show it there's something to show. Right now it's only generated if user changes something.
Now that Alertmanager provides status=(unprocessed|suppressed|active) in the API it doesn't make sense to keep having separate filters for each value, merge @silenced & @inhibited into a single filter, update docs and UI
Event listeners are setup on the modal div, but that div is not removed when the modal is hidden, only its children. This means that event listeners are stacked every time you show and hide a form. To reproduce this issue:
1. open silence form, click up button above hours, it will increment from 1 to 2
2. hide the form
3. re-open silence form, click up button above hours, it will increment from 1 to 3
4. repeat and every time increment will get a new listener that will cause higher value bump
This PR moves all listeners to the silence form element, which is removed when modal is closed, so all even listeners are destroyed properly and this bug no longer gets triggered.
Same fix is applied to the quick filter modal, it's present there but the effect there isn't as visible
There's a bogus duplicated mouse event for a.silence-duration-btn, which I added to fix css issues, get rid of it and replace with proper css selectors. And with that drop the event.stopPropagation call as it shouldn't be needed anymore
This moves raven init into a dedicated file where it's configured on load, we no longer load it on /help, but there's only css there so there wasn't anything that could fail anyway. We will also now fail in the most visible way if the value passed to raven is invalid (as in invalid syntax)
