fix: stop the file-viewer reload loop on watched files
Nightly Build / build (push) Successful in 7m35s

The watch callback forwarded every FS event, including the pure reads the
viewer's own GET /api/file produces (IN_ACCESS / IN_CLOSE_NOWRITE on Linux):
each silent reload re-triggered the watcher, looping at ~1 Hz. For PDFs every
iteration minted a new blob URL and re-assigned iframe.src, which re-runs
Chrome's whole PDF viewer (the flicker) and pushes a joint session-history
entry (the back button buried under hundreds of blob: entries).

- file_watch: forward an event only when the content version (mtime_ns, len)
  actually moved; drop Access events outright, stat-compare the rest.
- viewer: render pdf/latex/svg previews in a keyed() iframe — a fresh
  element's first navigation replaces its history slot instead of pushing.
This commit is contained in:
2026-08-04 16:19:37 +01:00
parent 88997ad256
commit e356741435
4 changed files with 59 additions and 12 deletions
+1
View File
@@ -52,6 +52,7 @@
"imports": {
"lit": "/vendor/lit-all.min.js",
"lit/directives/unsafe-html.js": "/vendor/lit-all.min.js",
"lit/directives/keyed.js": "/vendor/lit-all.min.js",
"marked": "/vendor/marked.esm.js",
"dompurify": "/vendor/purify.es.mjs"
}