- Shipped
- September 24, 2026 at 8:50 PM UTC
- Author
- Kamo
- Commit
- 4b3f26f
The badge and the list hear the same socket, and EmailService relays every arrival (verified on NATS: email.changed ARRIVED from both pods, then the unread snapshot that moves the badge). The list threw the change away whenever it held more than its first page, so reloading page 0 would not yank a reader back to the top. But the list pages without anyone scrolling: a return visit paints 25 cached rows, which sit inside the load-more threshold, so page 1 loaded at mount and no arrival reached the list again until the page was reloaded. The only other reload path waits for a RealtimeNotifier capability that no provider has. A change now fetches the first page and folds it into whatever is loaded (lib/email/liveListRefresh): new rows on top, flags from the server, rows gone from the first page's range dropped, deeper pages kept. The list keeps the rows on screen in place when mail lands above a reader scrolled down. A burst of change events is one request, started after the last of them, and never joined to a page-0 request that was already out before the change - that one may have read the folder without the new message. Verified in Chrome against the real MessageBrowser: first visit, after scrolling, a return visit, a reader scrolled deep, a delete elsewhere, and two arrivals on a slow server all show the change without a reload.