mi/werkbaum
1
0
Fork 0
Code Issues Pull Requests 3 Actions Packages Projects Releases Wiki Activity

docs: eingebettetes Pad — Update-Poller als Ursache ausgeschlossen (D31)

Browse Source 
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
Download Patch File Download Diff File Expand all files Collapse all files
frontend/CLAUDE.md
+7 -1
View File
@@ -169,7 +169,13 @@ verworfene Elemente. Quelle sind ES-Module unter `src/`; `index.html` ist der
`revealEditor()` schaltet 'pad' → 'both', sonst zeigte der Sprung (D25) ins
Nichts. Das Markup: `#srcArea` umschließt Rahmen + Splitter + `#src`, damit die
Legenden-Aufteilung unberührt bleibt — `.editor-body textarea` ist ein
Nachfahren-Selektor und greift weiter.
Nachfahren-Selektor und greift weiter. Nebenwirkung, die als Behelf taugt:
Einmal durch die Ansichten schalten **lädt den Rahmen neu** (über
`about:blank`) — das ist der Ausweg, wenn ein eingebettetes Pad nicht mehr
beschreibbar ist. Nicht in den Neu-laden-Knopf legen: der zieht nach dem Tippen
Spiegel und Diagramm nach, und ein Rahmen-Reload dabei kostete jedes Mal die
Schreibmarke im Pad. **Umhängen im DOM lädt jeden `<iframe>` neu** — wer
Container um `#srcArea` herum neu aufbaut, wirft die Pad-Sitzung weg.
- Fokusmarke `!!!` (D32, SPEC §1): Parser setzt `focus`, Renderer die Klasse
`focusmark`, CSS teilt die Regel mit `.node.current` (ein Begriff „hier
schauen"). Erkannt **nur alleinstehend** — `(^|\s)!!!(?=\s|$)`, bewusst ohne