Unread tracking: mark-all-read on tab hide erases unread for rooms the user never saw (mobile app-switch)

[sanity]

Found during adversarial review of #445 (mobile hamburger unread badge). Pre-existing behavior, affects three surfaces: the document-title count, the room-list badges, and (since #445) the hamburger badge.

Behavior

mark_all_rooms_as_read() (ui/src/components/app/document_title.rs) fires on every visible→hidden visibilitychange and marks every room read up to its latest message. Rationale in the code: "the user had the chance to see anything already in state."

That premise is desktop-title-centric. On mobile, switching apps fires visible→hidden, and rooms other than the current one were never on screen — yet their unread state is wiped. Scenario:

1. User is deep in room A on mobile; a message lands in room B → hamburger badge / rail badge show 1.
2. User switches to another app (visibilitychange → hidden) → all rooms marked read.
3. User returns → badges gone, though the room-B message was never seen.

So the unread indicators only hold within a single uninterrupted foreground session. On desktop the same wipe zeroes rail badges for rooms whose messages were arguably never "seen" either (a rail badge count is not the message).

Options

• Only mark the current room read on hide (other rooms keep unread until actually opened). Changes title semantics: the hidden-tab "(N)" would then show total accumulated unread, not just new-since-hide — arguably more useful, but a deliberate change.
• Keep mark-all on desktop, restrict to current-room-only on touch/mobile (no reliable signal; user-agent sniffing is ugly).
• Keep as-is and accept the reset (status quo).

Needs a product call since it changes long-standing title behavior. cc @sanity

[AI-assisted - Claude]

[sanity]

#459 (jump to first unread) depends on the product call this issue is waiting for. Option 1 above, only marking the current room read on hide, is what that feature needs: a jump-to-unread button is worse than nothing if the marker it points at gets erased by an app-switch.

Also worth noting this issue may be the underlying cause of the Matrix report that prompted #459 ("I have to figure out where to resume reading"), though that is a suspicion rather than a confirmed repro.

[AI-assisted - Claude]

[sanity]

Issue Priority Assessment

Generated: 2026-07-24T12:41:21.444244032+00:00
Issue hash: aac7ae77

Value Assessment

The issue is fully current: mark_all_rooms_as_read() at ui/src/components/app/document_title.rs:429-475 still unconditionally sweeps every room's last_read_message_id up to its latest message on every visible→hidden visibilitychange, exactly as described. Nothing in the codebase has scoped this to the current room. This isn't stale — it's live, load-bearing behavior on every desktop tab-switch and every mobile app-switch.

Relevance: confirmed still present and unresolved; the code and comment ("the user had the chance to see anything already in state") match the issue verbatim.

User impact: this hits every mobile user who app-switches while River is open in a background tab — a very common mobile usage pattern — and silently erases unread signals for rooms they never looked at. It's not a crash or data-loss bug, but it's a persistent, repeatable trust-eroding UX defect: unread badges become unreliable the moment you background the app, undermining the entire point of having them. Desktop users are affected too, in the milder "rail badge for a room you never opened" sense.

Strategic alignment: directly blocks #459 (jump-to-first-unread), which sanity explicitly says needs Option 1 (mark only the current room on hide) to be worth shipping — a jump-to-unread marker that gets wiped by a mere app-switch is worse than not having the feature. sanity also suspects this is the root cause of a real Matrix user complaint ("I have to figure out where to resume reading"), i.e., it's plausibly already causing live user-visible pain, not just a theoretical edge case.

Blocking factor: yes — #459 is explicitly stalled on the product decision this issue raises. Given the strong signal from sanity's comment (Option 1 is basically decided as the direction), this is close to shovel-ready: fix mark_all_rooms_as_read to only touch the currently-active room and adjust the title-count semantics accordingly. I'd rank this as a high-value, low-risk fix worth taking up soon, ideally bundled with or immediately before #459.

Cost Assessment

Now I have enough context to write the assessment.

The core function, mark_all_rooms_as_read() (ui/src/components/app/document_title.rs:430-480), is exactly as the issue describes and hasn't drifted — the fix is localized to this one file. The option the issue and @sanity's comment converge on ("only mark the current room read on hide") is a small, mechanical change: in on_visibility_change() (line 493-499), swap the mark_all_rooms_as_read() call for something closer to mark_current_room_as_read() (already used on the visible-transition branch, line 492), or simply delete the hide-branch call entirely so unread state only advances on the explicit visible-room-viewed path. mark_current_room_as_read() (line 366+) already does the per-room, delegate-saving, title-updating work this needs — no new primitive is required.

The main complexity is not the code change itself but reasoning through what "count in title" means afterward: today the hidden-tab "(N)" title reflects only unread-since-hide; switching to current-room-only marking changes it to reflect total accumulated unread across all rooms (as the issue notes explicitly), which is a user-visible behavior change to a "long-standing" feature the issue says needs a product call before implementation — that call from @sanity now leans toward option 1, but no one has explicitly signed off on the title semantics change yet, so there's a small non-code coordination cost (confirming intent) before landing it. There's also a subtlety worth checking: whether mark_all_rooms_as_read is relied on anywhere else (e.g., to keep TOTAL_UNREAD_COUNT bounded or avoid stale badges after very long sessions) — a quick grep shows its only caller is on_visibility_change's hidden branch, so removing/narrowing it is safe and self-contained.

Risk is low-to-moderate: this touches unread-count logic feeding three surfaces (document title, room-list badges, hamburger badge per #445), so a regression would be visible but not data-destructive (no contract/delegate WASM involved, no migration needed — this is pure UI-state logic, #[serde(skip)]-adjacent in-memory bookkeeping saved via the existing delegate-save path). Testing is straightforward: the file already has a substantial mod tests block (lines 572-970+) with pure-function-style tests around last_read_message_id/count logic, so a new test simulating "room B unread while room A is foregrounded, then hide, then check room B's last_read_message_id unchanged" fits the existing pattern without needing a browser harness. Given the localized diff, existing test scaffolding, and the only real dependency being a product-intent confirmation (largely already given via @sanity's comment), this is a low-cost issue — roughly a half-day task including tests, with #459 (jump-to-unread) as a motivated downstream beneficiary.

---

Generated by issue-prioritizer