- Previously, in case of `abort` the url was already pushed to history at the beginning of `onFailure`, setting `addToHistory` to true only prevents it from being added twice (again in `onComplete`).
- Now we only push the url to history in `onComplete`, so setting `addToHistory` to false is only necessary if req is scripted.
- We intentionally push the canceled url into history to continue navigating with the browser`s back/forward key.
Not the container's base target. The redirect target may still be
overridden by `data-base-target` on the `form` or by the response
using `X-Icinga-Container`.
* Let response header `X-Icinga-Container` either influence a request's `$target` or `$redirectTarget`, but not both
* Close a request's `$target` instead of the `$redirectTarget` upon the redirect url `__CLOSE__`
* Issuing a `__CLOSE__` in a detail url still closes `#col2` and refreshes `#col1`
* Issuing a `__CLOSE__` for a nested container still empties it
* Issuing a `__CLOSE__` in a modal, now refreshes the modal openers container
* If `X-Icinga-Extra-Updates` is set, automatic refreshing won't happen
Search requests are handled elsewhere in a more dynamic
way since .. some time. This part also used to be active
only in case Icinga Web is hosted at the root of the web
server, which many users don't do as otherwise we would
have gotten more reports in the past regarding the reload
animation. Or rather, about the login not working due to
the same reason.
It's gone for good now.
fixes#4834
..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.
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.
