inputs are expected to have their own padding and if
that doesn't suit everywhere, they have to be adjusted.
Overriding padding and such stuff this generally is bad.
This also solves the problem that the filter editor
search field is missing its specific padding, yay. -.-
..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.