Pick up a new version without pressing Reload, when it's safe to #1341

New issue

Closed

opened 2026-11-05 22:04:02 +00:00 by claude-bot · 1 comment

claude-bot commented

2026-11-05 22:04:02 +00:00

Collaborator

The owner, 2026-11-05: "the requirement that I manually reload after an update is annoying and I'd like to see if we have other options." For a future release.

Today (D13, #736):

The service worker is registerType: "prompt" with no skipWaiting. When a new build is waiting, StatusBanners shows "Reload to use the new version. Nothing you have typed is lost." with a Reload button (src/pwaUpdate.js).
Why: D13 chose this so a waiting update could never swap the app under someone mid-form.
The one automatic reload: src/newVersion.js reloads once, saying "Quest Board has been updated. Fetching the new version…", when an old tab asks for a code chunk that no longer exists.

Options (not exclusive):

Apply it at the next safe moment, without asking. When an update is waiting, take it at whichever comes first:
- an in-app page change (moving between pages is already a natural break);
- the tab going to the background (visibilitychange → hidden), so you return to the new version;
- a minute or two of no input.
In each case, only when nothing is unsaved: the editors, sheets and forms already know when they're dirty, and a small shared "unsaved work" registry would let this check. With unsaved work, it waits for the next safe moment.
Keep the banner only as the fallback, for when unsaved work has kept it from applying for a long time. It would be quieter, because it would rarely appear.
Make old tabs keep working across a deploy: keep the previous build's code chunks on the server for a while, so a tab that never reloads doesn't break. That makes waiting for a safe moment cost nothing, and the forced "Fetching the new version…" reload would almost never be needed.
Go back to updating instantly (autoUpdate with skipWaiting). This is the simplest, but it brings back what D13 avoided, so I wouldn't recommend it.

Recommendation: 1 and 2 together, with 3 if cheap. You'd normally never see a reload, and nothing typed is ever at risk.

Release: new behaviour, so an X.Y.0. Draw it (the banner's fallback state) and confirm the "safe moment" rules with the owner first.

**The owner, 2026-11-05:** "the requirement that I manually reload after an update is annoying and I'd like to see if we have other options." For a future release. **Today (D13, #736):** - **The service worker** is `registerType: "prompt"` with no `skipWaiting`. When a new build is waiting, `StatusBanners` shows "Reload to use the new version. Nothing you have typed is lost." with a **Reload** button (`src/pwaUpdate.js`). - **Why:** D13 chose this so a waiting update could never swap the app under someone mid-form. - **The one automatic reload:** `src/newVersion.js` reloads once, saying "Quest Board has been updated. Fetching the new version…", when an old tab asks for a code chunk that no longer exists. **Options (not exclusive):** 1. **Apply it at the next safe moment, without asking.** When an update is waiting, take it at whichever comes first: - an in-app page change (moving between pages is already a natural break); - the tab going to the background (`visibilitychange` → hidden), so you return to the new version; - a minute or two of no input. In each case, only when nothing is unsaved: the editors, sheets and forms already know when they're dirty, and a small shared "unsaved work" registry would let this check. With unsaved work, it waits for the next safe moment. 2. **Keep the banner only as the fallback,** for when unsaved work has kept it from applying for a long time. It would be quieter, because it would rarely appear. 3. **Make old tabs keep working across a deploy:** keep the previous build's code chunks on the server for a while, so a tab that never reloads doesn't break. That makes waiting for a safe moment cost nothing, and the forced "Fetching the new version…" reload would almost never be needed. 4. **Go back to updating instantly** (`autoUpdate` with `skipWaiting`). This is the simplest, but it brings back what D13 avoided, so I wouldn't recommend it. **Recommendation:** 1 and 2 together, with 3 if cheap. You'd normally never see a reload, and nothing typed is ever at risk. **Release:** new behaviour, so an X.Y.0. Draw it (the banner's fallback state) and confirm the "safe moment" rules with the owner first.

claude-bot added this to the v4.8.0 - A Living World Fills In milestone

2026-11-06 01:28:19 +00:00

claude-bot commented

2026-11-06 15:35:11 +00:00

Author

Collaborator

Decided (owner, 2026-11-06, Q239–Q242; D339), and being built now:

When it applies: an update applies itself at the first safe moment, whichever comes first:
- an in-app page change;
- the tab going to the background;
- 2 minutes without input.
Only when nothing is unsaved. That's known from the leave guard (D22), so no per-editor wiring is needed.
Never on the table page or a live session's page. It waits until the GM leaves.
Fallback: today's Reload banner appears only if the update has waited 30 minutes.
Afterwards: a short notice, "Quest Board was updated."

**Decided (owner, 2026-11-06, Q239–Q242; D339), and being built now:** - **When it applies:** an update applies itself at the first safe moment, whichever comes first: - an in-app page change; - the tab going to the background; - 2 minutes without input. - **Only when nothing is unsaved.** That's known from the leave guard (D22), so no per-editor wiring is needed. - **Never on the table page or a live session's page.** It waits until the GM leaves. - **Fallback:** today's Reload banner appears only if the update has waited 30 minutes. - **Afterwards:** a short notice, "Quest Board was updated."