diff --git a/README.de.md b/README.de.md index 38e5b2f..82fe462 100644 --- a/README.de.md +++ b/README.de.md @@ -139,7 +139,12 @@ löscht. für jeden lesbar, der die Adresse kennt. Im eingebetteten Rahmen wird Etherpads Autoren-Cookie (`SameSite=Lax`) nicht mitgesendet — man gilt bei jedem Laden als neuer Autor, was nur serverseitig zu beheben ist (`cookie.sameSite: "None"`). -Siehe `docs/DECISIONS.md` D31 und D32. + +Aus demselben Grund ist der eingebettete Rahmen vor allem zum **Mitlesen** gut: +Sollte das Bearbeiten darin einmal aufhören zu funktionieren, den Ansichts-Wähler +einmal durchschalten (das lädt den Rahmen neu) oder über „im Pad bearbeiten" im +eigenen Tab weiterarbeiten, wo das Cookie gilt. Siehe `docs/DECISIONS.md` D31 +und D32. ### Lokal ausführen diff --git a/README.md b/README.md index 30c7294..3d1bced 100644 --- a/README.md +++ b/README.md @@ -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 diff --git a/docs/DECISIONS.md b/docs/DECISIONS.md index df02f78..f2dbb55 100644 --- a/docs/DECISIONS.md +++ b/docs/DECISIONS.md @@ -1238,3 +1238,49 @@ Notwendigkeit (§3) — test-abgedeckt, damit niemand später Status oder `optio daran koppelt. **Nicht** in das kanonische Beispiel (SPEC §10) aufgenommen: Das ist zugleich Test-Fixture, und ein dauerhafter Zeigefinger darin wäre eine Aussage, die niemand gemacht hat. + +**Nachtrag zu D31 — „der eingebettete Rahmen lässt sich nach einer Weile nicht +mehr bearbeiten".** Gemeldet vom Nutzer, mit dem Verdacht, es hänge am +Update-Poller. **Der ist es nicht**, und das ist belegbar statt vermutet: + +- `checkForUpdates()` holt `location.href`, also den **Werkbaum**-Origin. Es kann + die Drosselung des Pads (10 Abrufe je 90 s, siehe oben) gar nicht auslösen. +- Es lädt die Seite nicht neu, sondern zeigt nur ein Banner; + `checkAndShowUpdateNotification()` und `showUpdateDebug()` hängen ausschließlich + `position:fixed`-Elemente an `` — kein Neuaufbau eines Containers, in dem + der Rahmen steckt (das *würde* ihn neu laden, denn ein Umhängen im DOM lädt + jeden `