Skip to content

Control scroll position on edited/inserted/etc. messages #1536

Open
@gnprice

Description

@gnprice

This is a follow-up to #83: when looking at the message list, the messages on the screen can suddenly jump when certain changes happen.

The cases of a new message in a message event, or messages newly fetched on scroll, were covered by #1507; new messages now appear in the downward-growing bottom sliver instead of the upward-growing top sliver (which had been effectively the only sliver until recently). In the #1507 description these were called cases (a) and (b).

This issue is that the messages on the screen can still jump when any of a variety of less-common events occur. As described in #1507, those are: (c) deleting messages, or moving them away, when they're not the very oldest or latest; (d) moving messages into the middle of the list; (e) likely on some cases of editing messages so that their height changes; (f) similarly on a message going from no reactions to some reactions or back, or other changes that affect its displayed height.

Implementation

For (c) and (d), I think the Flutter API has the hooks we'd need (we'd make our own implementation of RenderSliverBoxChildManager), but fundamentally it's a subtle problem; in particular we'd need a richer data structure for the list of messages than a List or Queue.

For (e) and (f), and for that matter as a possible alternative solution for (c) and (d) or even (a) and (b), I believe we could use a ScrollController. When something changes, we'd calculate what the right scroll position is in the new state of things, and call jumpTo to go there. Or perhaps we'd override ScrollController.createScrollPosition? The example of PageController, mentioned in that doc, sounds potentially promising as a model.

Specifically we have at this point our own ScrollController and ScrollPosition subclasses, namely MessageListScrollController and MessageListScrollPosition, which were introduced in the PRs leading up to #1507 in order to handle some related needs. So this latter solution would mean making further changes there.

Metadata

Metadata

Assignees

No one assigned

    Labels

    a-msglistThe message-list screen, except what's label:a-content

    Type

    No type

    Projects

    Status

    No status

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions