fix(reader): read position from the API at open; never write a restored position
The reader page embedded a snapshot of reading state (position, bookmarks) server-side at render time. Browsers may reuse that HTML (heuristic caching, bfcache), so opening a book could restore a stale position — and worse, the restore's relocate auto-saved it back, overwriting a newer device push minutes later. A KOReader sync followed by opening the web reader would silently revert the row to the old web position; the row's source and the rendered page disagreed. The web reader is intrinsically tied to the server, so it has no business preserving reading state client-side: - The rendered page now carries only immutable book metadata. The reader fetches progress fresh (cache: no-store) from the existing progress API at open and restores with the same priority as before (page for fixed-layout, CFI, percentage, fresh start); a failed fetch opens at the start and writes nothing. Initial bookmarks likewise come from their endpoint instead of the embed; annotations already did. - Progress saves are gated on deliberate navigation only (page turns, keys, slider, search/TOC/bookmark/back-stack jumps, tap zones — each marks the session as user-moved). Restores and section-load relocations never write, so displaying a position can no longer clobber a newer one. A bfcache-resurrected page resets the flag and cannot write its frozen position either. This replaces the old five-second post-init suppression, which a stale page bypassed. - The server-rendered initial progress badges render a neutral placeholder until the first relocate fills them (sub-second). No API, schema, or sync-engine changes. Normal reading saves exactly as before — the first save now simply waits for the first real page turn.
This commit is contained in:
+39
-128
File diff suppressed because one or more lines are too long
Reference in New Issue
Block a user