jcoffey-dev
d64249b46d
Selecting a thread put you at the newest message. Anything unread above that sat off the top of the pane with nothing to announce it, and the only way to find out was to scroll up -- by which time the auto-mark-read timer had marked the whole thread read anyway, so scrolling up meant scrolling up to mail already counted as seen (#87). Opening at the bottom is right when there is nothing to catch up on and wrong the moment there is. The pane now opens on the oldest message that was unread when the thread was opened, and falls back to the newest when the thread has already been read. mbunkus's out-of-order case is the one that rules out guessing at a position. A participant whose server could not connect for hours delivers a message long after it was written, and it lands in the middle of a conversation that has already moved past it -- so "second to last", or any other fixed offset from the end, finds nothing. Reading the unread set is the only thing that does. Two cases leave the pane where it is: - a single message, which is already the whole pane - the first unread being the first message, where the top of the pane shows it anyway, together with the subject; scrolling to it would push the subject off for nothing It reads the set captured when the thread was opened rather than live `$seen` state, for the same reason expansion does (#69): the mark-read timer must not change the shape of what you are looking at. That also makes the landing stable, because everything above the first unread message is a collapsed row of fixed height -- nothing up there reflows after the scroll. The mock grows a thread that reproduces it: seven messages with the unread one second, four more behind it. Verified against it. Opening the thread lands the unread message flush against the top of the pane at scrollTop 158; the old scroll to the newest message put it at 445, with 287px of the message -- header, sender and unread bar included -- above the fold. On a thread whose first message is the unread one the pane stays at 0 with the subject in view, where before it would have scrolled 333. Once the thread is read, reopening it goes back to the newest message.
36 lines
1.6 KiB
TypeScript
36 lines
1.6 KiB
TypeScript
/**
|
|
* Where a conversation opens.
|
|
*
|
|
* It used to open on the newest message, which is wrong whenever anything in
|
|
* the thread is unread: the unread mail sits above the fold, and the only clue
|
|
* it exists is the marker on a message you have to scroll up to find. The
|
|
* auto-mark-read timer then sweeps the whole thread, so scrolling up late is
|
|
* scrolling up to mail that is already marked read (#87).
|
|
*
|
|
* Order is receivedAt, not arrival, so the first unread is not the second-to-
|
|
* last message or any other position you can guess at. A thread where one
|
|
* participant's server queued a message for hours delivers it late and sorts it
|
|
* early -- exactly the case where opening at the bottom hides the most.
|
|
*
|
|
* Two answers are "don't move":
|
|
*
|
|
* - a single message, which is already the whole pane
|
|
* - the first unread being the first message, where the top of the pane
|
|
* shows it anyway, together with the subject
|
|
*
|
|
* `unread` is the set captured when the thread was opened rather than live
|
|
* `$seen` state, for the same reason expansion uses it: the mark-read timer
|
|
* must not change the shape of what you are looking at (#69).
|
|
*/
|
|
export function threadScrollTarget<T extends { id: string }>(
|
|
messages: readonly T[],
|
|
unread: ReadonlySet<string>,
|
|
): string | null {
|
|
if (messages.length < 2) return null;
|
|
const firstUnread = messages.findIndex((m) => unread.has(m.id));
|
|
if (firstUnread === 0) return null;
|
|
if (firstUnread > 0) return messages[firstUnread]!.id;
|
|
// Nothing unread: the newest message, which is what you came for.
|
|
return messages[messages.length - 1]!.id;
|
|
}
|