docs: eingebettetes Pad — Update-Poller als Ursache ausgeschlossen (D31)
Gemeldet: Das eingebettete Etherpad lässt sich nach einer Weile nicht mehr bearbeiten; Verdacht auf den Update-Poller. Der ist es nicht, und das ist belegt statt vermutet: - `checkForUpdates()` holt `location.href`, also den Werkbaum-Origin — es kann die Pad-Drosselung gar nicht auslösen. - Es lädt die Seite nicht neu; `checkAndShowUpdateNotification()` und `showUpdateDebug()` hängen nur `position:fixed`-Elemente an `<body>`. Kein Neuaufbau eines Containers um den Rahmen — der WÜRDE ihn neu laden, weil ein Umhängen im DOM jeden `<iframe>` neu lädt. - Gemessen über ~6 Minuten: window-Marker überlebt (kein Seiten-Reload), `load`-Zähler am Rahmen bleibt 0 (kein Rahmen-Reload), Sichtbarkeit durchgehend `visible`. Reproduziert wurde der Fehler nicht. Nach sechs Minuten lief die Verbindung noch — geprüft ohne Tippen, indem das Pad von außen geändert wurde: der Rahmen übernahm die Änderung sofort. Etherpads eigene Meldungen sind von außen nicht lesbar (fremdstämmiger Rahmen, eigener Konsolen-Kontext). Als Verdacht festgehalten, ausdrücklich unbewiesen: das `SameSite=Lax`-Cookie. Die erste Verbindung gelingt, aber beim Wiederaufbau nach einem Abbruch fehlt die Autoren-Identität — sichtbar, aber nicht mehr beschreibbar. Passt zu „nach einer Weile" und dazu, dass es im eigenen Tab nicht auftritt. Der entscheidende Test gehört dem, der es sieht: Pad im eigenen Tab öffnen. Geht es dort, ist es der Dritt-Kontext (nur serverseitig zu beheben). Klemmt es dort auch, liegt es am Pad. Behelf ist schon eingebaut: Einmal durch den Ansichts-Wähler schalten lädt den Rahmen neu (über `about:blank`). Bewusst NICHT in den Neu-laden-Knopf gelegt — der zieht nach dem Tippen Spiegel und Diagramm nach, und ein Rahmen-Reload dabei kostete jedes Mal die Schreibmarke im Pad.
This commit is contained in:
@@ -131,8 +131,12 @@ ordinary label. It stays in the text until someone deletes it.
|
||||
**Be aware:** your plan text then lives on third-party infrastructure, and a pad
|
||||
is readable by anyone who knows its address. In an embedded frame Etherpad's
|
||||
author cookie (`SameSite=Lax`) is not sent, so you count as a new author on every
|
||||
load — fixable only on the server (`cookie.sameSite: "None"`). See
|
||||
`docs/DECISIONS.md` D31 and D32.
|
||||
load — fixable only on the server (`cookie.sameSite: "None"`).
|
||||
|
||||
For the same reason the **embedded frame is best for reading along**: if editing
|
||||
in it ever stops working, cycle the view selector once (that reloads the frame),
|
||||
or use the "edit in the pad" button and work in the pad's own tab, where the
|
||||
cookie does apply. See `docs/DECISIONS.md` D31 and D32.
|
||||
|
||||
### Running it locally
|
||||
|
||||
|
||||
Reference in New Issue
Block a user