[Live] Refresh Suchtimer Seite nach Anlegen eines neuen Suchtimers

Spekulation: Edge macht keinen Reload der Seite wenn ich mit "history.go(-1);" auf diese Seite zurückgehe.

Das liegt daran, dass mit dem Redirect eine neue Seite, sprich: ein neuer History-Kontext entsteht, für den noch keine Scroll-Position gespeichert wurde.

Beides lässt sich nicht wirklich gut verbinden, weil man dann für jede URL die Scroll-Position per Cookie speichern müsste. Datentechnisch wäre das ein ziemlicher ein Irrsinn. Zumal man dann eine bereits "bekannte" URL kaum noch "normal" (also ohne automatischen Sprung zur letzten Scroll-Position) laden könnte...

PS: Beim Überarbeiten der Speicherung der Scroll-Position hat sich übrigens gezeigt, dass Chrome/Edge das von Google veröffentlichte Zustandsmodell nicht einhalten, also eher die auf der Chrome-Engine fußenden Browser diesbezüglich "Quell ewiger Freude" sind.

Ich habe mal ein wenig gegoogelt. Möglicherweise kann ich eine Verbesserung für Chrome/Edge erzielen. Aber gebt mir bitte ein bisschen Zeit, OK?

Der folgende Patch:

• The content cannot be displayed because you do not have authorisation to view this content.

…sollte das Problem beheben. Seiten, die einen Reload der Vorgängerseite benötigen, können diesen vor Aufruf von history.go() als Request im Session-Storage hinterlegen. Wenn die Seite aus der History abgerufen wird, triggert das pageshow-Event die Auswertung des Flags und führt bei Chrome-basierten Browsern den Reload aus. Bei Firefox ist das Brimborium nicht notwendig, weshalb für diesen Browser der Reload nicht ausgeführt wird.

Den Reload-Request habe ich im Code vor allen Aufrufen von history.go() eingefügt und sollte damit an jeder relevanten Stelle platziert sein. Eventuell bräuchte man ihn an der einen oder anderen Stelle überhaupt nicht; er schadet aber auch nicht. Bitte testet den Patch und gebt Bescheid.

MarkusE, mir ist bei der Suche nach dem richtigen Hook noch eine Kleinigkeit bezüglich des Aufrufs von restoreScrollPosition() aufgefallen:

--- a/live/js/live/scripts.js
+++ b/live/js/live/scripts.js
@@ -184,7 +199,7 @@ function handleScrollPosition(id, autoRestore = true) {
     if (autoRestore) {
       addEventListener("pageshow", (event) => {
         if (logToConsole) console.log(`Event:    pageshow @ ${window.location.href}`);
-        restoreScrollPosition(id);
+        restoreScrollPosition();
       });
     }
     handleScrollPosition.registered = true;

Die Funktion benötigt keinen Parameter und ignoriert id deshalb.

Wir müssen zwei Szenarien unterscheiden:

• Edge macht keinen Reload bei der Rückkehr auf die Vorgängerseite. Der Patch adressiert genau dies.
• Der Reload erfolgt schneller, als der VDR die geänderten Daten an Live zurückliegen. Da kann auch der Patch nicht helfen.

Beim Anlegen eines Suchtimers mit Edge war dieser bei mir nach dem Speichern und automatischen Reload der Suchtimer-Übersicht jedenfalls sofort in der Liste enthalten.

Der Patch an sich ist sicherlich sinnvoll und sollte wohl ins Git. Den anderen Aspekt der Race-Conditions muss Markus angehen. Ich erinnere mich aber dunkel, dass wir das Thema schon einmal hatten und Markus nicht eingreifen wollte…

PS: Habe den Patch um ein paar Debug-Ausgaben erweitert.

Klar verbessert der Patch etwas: er aktualisiert nämlich die Anzeige um zwischenzeitlich bei Live eingetroffene Daten und sorgt dafür, dass sich Firefox und Chrome/Edge diesbezüglich identisch verhalten. Dass bei einer hinreichend großen Anzahl die gerade erfolgte Änderung nicht (immer) gleich dabei ist, ist (leider) nichts Neues. Da muss – wie gesagt – MarkusE ran; mal sehen, ob er sich der Sache annehmen will.

Den Redirect darfst du dir natürlich gerne lokal reinpatchen, dafür geht halt dir die Scroll-Position bei der dadurch vollständig neu geladenen und gerenderten Seite (die aufgrund des Redirects ja die letzte in der History is) verloren. Insofern wäre das für die Allgemeinheit wohl eher ein Rückschritt.

PS: Außerdem werden Edit-Dialog meist von mehr als einer Stelle aufgerufen. Ein Redirect zu einer festen Seite ist also auch kontraproduktiv…

Das kann noch immer eine Race Condition sein, weil der Redirect eventuell mehr Zeit erfordert. Aber geh doch bitte in den Inspektor und setze (bei Verwendung von Patch 45a) einen Breakpoint auf diese Stelle:

The content cannot be displayed because you do not have authorisation to view this content.

Dann zeigt sich doch ganz schnell, ob ein Reload erfolgt. Bei mir nach dem Bearbeiten eines Suchtimers:

The content cannot be displayed because you do not have authorisation to view this content.

… ist das der Fall. Und dass der Reload auch wirklich ausgeführt wird, habe ich geprüft, indem ich während des Wartens am Breakpoint mit einem anderen Browser einen weiteren Suchtimer angelegt habe. Dieser wird nach nach einem Step-Over auch angezeigt.

Eventuell könnte man den Rücksprung per history.go() noch um ein paar Millisekunden verzögern. Das ist zwar nicht perfekt, aber als Workaround vielleicht gut genug…

Hiermit:

const refreshPageTimeout = 10;  // ms

function refreshPage() {
  const reference = sessionStorage.getItem(settings.sessionStoragePageRefresh);
  sessionStorage.removeItem(settings.sessionStoragePageRefresh);
  if (reference) {
    if (navigator.userAgent.includes("Chrome")) {
      refreshPage.timeout = setTimeout(() => {
        if (logToConsole) console.log(`Reload:   refresh @ ${reference}`);
        location.reload();
      }, refreshPageTimeout);
    } else {
      // Firefox reloads by default
      if (logToConsole) console.log(`Skipped:  refresh @ ${reference}`);
    }
  }
}

… ist auf meinem Produktivsystem auch bei ca. 180 Suchtimern ein neuer Suchtimer gleich angezeigt worden, ohne die paar Millisekunden aber nicht. Bemerken wir man diese minimale Verzögerung in der Regel wohl nicht.

Nach ein bisschen Herumspielen drängt sich mir der Eindruck auf, dass es vor allem darauf ankommt, den Reload per Event-Prozedur zu entkoppeln, denn selbst ein Timeout von 1 ms ist ausreichend.

Anbei der aktualisierte Patch (falls ihr ihn überhaupt noch haben wollt).