You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Thanks to all the preparatory changes we've made in this commit
series and those that came before it, this change should have only
subtle effects on user-visible behavior.
This therefore serves as a testing ground for all the ways that the
message list's scrolling behavior can become more complicated when
two (nontrivial) slivers are involved. If we find a situation where
the behavior does change noticeably (beyond what's described below),
that will be something to investigate and fix.
In particular:
* The sticky headers should behave exactly as they did before,
even when the sliver boundary lies under the sticky header,
thanks to several previous commit series.
* On first loading a given message list, it should start out
scrolled to the end, just as before.
* When already scrolled to the end, the message list should stay
there when a new message arrives, or a message is edited, etc.,
even if the (new) latest message is taller than it was.
This commit adds a test to confirm that.
Subtle differences include:
* When scrolled up from the bottom and a new message comes in,
the behavior is slightly different from before. The current
exact behavior is something we probably want to change anyway,
and I think the new behavior isn't particularly better or worse.
* The behavior upon overscroll might be slightly different;
I'm not sure.
* When a new message arrives, the previously-latest message gets a
fresh element in the tree, and any UI state on it is lost. This
happens because it moves between one sliver-list and the other,
and the `findChildIndexCallback` mechanism only works within a
single sliver-list.
This causes a couple of visible glitches, but they seem tolerable.
This will also naturally get fixed in the next PR or two toward
#82: we'll start adding new messages to the bottom sliver, rather
than having them push anything from the bottom to the top sliver.
Known symptoms of this are:
* When the user has just marked messages as read and a new message
arrives while the unread markers are fading, the marker on the
previously-latest message will (if it was present) abruptly
vanish while the others smoothly continue fading.
We have a test for the smooth fading, and it happened to test
the latest message, so this commit adjusts the test to avoid
triggering this issue.
* If the user had a spoiler expanded on the previously-latest
message, it will reset to collapsed.
0 commit comments