-
Notifications
You must be signed in to change notification settings - Fork 350
Description
There's a symptom I've seen happen just a couple of times, and just now while working on the sticky-header code (for #82) I realized what's causing it and how to fix it.
Repro recipe:
- Scroll up in history, a screenful or two past some message that you sent and can still edit.
- From a different client, edit that message to be much taller than it was.
- Scroll back down quickly, say by using the scroll-to-end button.
The result might look like this:
| Actual | Expected |
|---|---|
![]() |
![]() |
Note the big gap above the "3" message; the recipient header at the very bottom of the list; and the recipient header out of order relative to the message (it has the wrong text for any later message).
Other times the gap can be smaller, like the height of a short message.
I saw a similar gap as part of #725. It's possible the cause of this issue was also the root cause of #725.
Diagnosis
The cause of the issue is that the sticky-header implementation isn't properly handling one aspect of the sliver layout protocol. Specifically, when _RenderSliverStickyHeaderListInner.performLayout produces a SliverGeometry with scrollOffsetCorrection non-null, _RenderSliverStickyHeaderList.performLayout is swallowing that information instead of passing it on to its parent.
I'll send a fix as part of the sticky-headers PR I'm developing for #82.
Metadata
Metadata
Assignees
Labels
Type
Projects
Status

