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:
mhoennig
2026-07-30 13:38:19 +02:00
parent 816a77d9e7
commit 6917b420d8
4 changed files with 65 additions and 4 deletions
+6 -2
View File
@@ -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