Links with the same URL may still be user-triggered actions, which should cause the auto-refresh to be stalled. The old implementation assumed that user-triggered requests always have a different URL.
fixes#8975
The commit ae68e8aec4 reverted
earlier seems to be supposed to do exactly what this one does now.
Prior, the commits ae68e8aec4 and
8bb0e4e0a0 were effectively
neutralizing each other. Quick tests of how Web 2 handles failing
requests while interacting with the browser's history were successful.
If this change breaks something else (again?), leave me a note and do
*not* fix it straight away..
This fixes the problem when redirecting from a form using the same route
as in the leftmost column but with a different querystring, that one gets
the same route shown twice.
Allow to change url's in history and stop auto auto refresh if
the container URL is not up to date.
Use variable after ajax call and the check is more robust.
This is not affected anymore because the errors goes directly
into the container. But this commit fixes the codes if someone
use the notifications in the loader. Also remove unused
variable this.exception.
fixes#6278
This used to be ways too slow when many elements where involved. Left
the old code there as a reminder. In case we really need it we should
use something faster like an overlay or so.
Listen for changes in form elements and abort all reloads that contain a form with
at least one changed form element. Do not refresh containers that contain a focused form
element, except of elements with autofocus, to preserve form elements with a dropdown.
Only focus autofocus elements when there is currently no other selection.
refs #7146
refs #5537fixes#7162
I'm unsure whether this is a jQuery bug or not. The removeData()
function has no effect unless there is a matching data attribute.
Makes IMO no sense, as adding the attribute automagically adds data,
so why should removing it differ.
This patch makes sure that the corresponding attribute is removed too.
Fixes "dashboard sometimes flickering on refresh".
refs #6536
Our redirection helper catching forms redirecting to their source
while being shown right-hand left a pending request. Abort was triggered,
but had no effect as the request has already been completed.
fixes#6619
An XHR redirection in a right-side container pointing to the URL
shown on the left should close it's own container and refresh the
lefthand one.
refs #6436fixes#6435
When redrawing a container we should cancel it's subcontainers pending
requests. This also fixes stopPendingRequestsFor(), it didn't really
work before.
Once replacing the whole layout we used to override notifications.
This is now fixed, they are going to be detached and re-attached
before and after re-rendering the page content.
Well... I didn't want to commit this before creating single-button
forms for enabling/disabling modules. However part of this accidentally
made it through, so let's finish it.
Still some work to do, but it already looks far better like this.
refs #4095
Just playing around, I'm still unsure whether this really helps. The
motivation behind this patch are icons loaded again after not being
displayed for a little while.
Remains disabled unless we know whether and for which scenarios
(cache disabled, HTTPS...) this really helps.
We would loose our focus if autorefresh takes place. So we don't render
the new content in case a form field in the very same container carries
the focus. It would be great to have a better solution one far day, but
for now it plays fine like this.
SVG chart was fetched although we removed image tags
from DOM. This happens when text is converted into
browser DOM model to use with javascript. Small
regex remove img source attribute to avoid using
network bandwidth for unknown resources.
fixes#6124
First step: get rid of the messy workaround for the problem that
notifications got lost once the whole body is re-rendered. This
should be solved either on server side or by detaching and re-
attaching existing notifications in such scenario.
Especially on browsers with slow JS like IE8 iterating again and again
over all rows used to harm response rendering. Immagine a dasboard with
a total of a few hundred rows refreshing every 10 seconds while taking
3 secs to render one dashlet... it's far better right now.
refs #6417
Ongoing error handling cleanup silently dropped notifications for
requests with "invalid" target (e.g. commands not redirecting after
submission - they should not exist, but they do).
This is redundant code, but that's ok for now - response handling will
be restructured.
fixes#6327
refs #6280
This is just a first step, trying to catch a few gotchas:
* it doesn't send notifications to the browser when issueing a redirect
as redirects can currently not be catched in jQuery response handlers
* it tries to find a better notification handling place in the response
handler (JS) - still imperfect
* it explicitely stores sessions once modified by notifications. Still
need to crosscheck whether this is really needed and how we can get
rid of this.
refs #6280
I missused the "impact" CSS class for this as it perfectly fit's this
use case. A container loading slow IS an impact. Added CSS transitions,
this way it feels better on modern browsers. The longer it takes to
load a page the darker will get it's background.
Johannes Meyer
Eric Lippmann
Matthias Jentsch
Marius Hein
Thomas Gelf
Gunnar Beutner