You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
watch: fix live reload for browse/mostrecent pages
The browse page watcher (handleWatchBrowse) had no hash-based catch-up
mechanism, so changes during the brief page reload window were lost.
To fix this, make browse content deterministic (move relative timestamps
to client-side JS) so that the content hash is stable across renders.
Then use the same hash-based catch-up that regular page watching uses:
re-generate the browse content, compare hashes, notify if different.
Also close the EventSource before calling location.reload() to prevent
the browser auto-reconnect from racing with the page reload:
location.reload() is asynchronous — JS keeps running briefly after the
call. During that window the browser tears down the SSE connection, and
EventSource interprets that as a network error, triggering its built-in
reconnect. The reconnected request races with (or even outlives) the
page unload, potentially resulting in duplicate SSE connections. The
existing unload/pagehide handlers cannot prevent this because they fire
asynchronously and may not run before EventSource reconnects. Calling
updates.close() synchronously inside onmessage (the same thing
unwatch() already does) is the only reliable fix.
Switch browse.js from async to defer: the script now queries
<time datetime> elements to add relative timestamps client-side, so it
must run after the DOM is fully parsed. With async, the script could
execute before those elements exist.
Preserve query parameters in the watch URL (URLSearchParams(u.search)
instead of URLSearchParams()) so that browse page parameters (dir, sort,
sortorder, directories) reach handleWatchBrowse for correct hash
comparison.
Generated using Claude Opus 4.6
0 commit comments