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
The primary difficulty with this is that, if we just hide the events (or, equivalently, collapse them into a group, EventListSummmary-style), the client will see that we have a bunch of empty space and attempt to backpaginate ... forever, until the start of the room.
It might be that we can apply a heuristic - once we've seen 1000 pre-join UTDs in a row, we stop back-paginating - but we need to be careful not to re-introduce element-hq/element-web#22671.
In particular, the danger is:
Alice joins a room and starts having a conversation with Bob
Lots of delayed messages from Charlie turn up, from before Alice was in the room. These are Expected UTDs.
Alice switches room back and forth in her client (thus clearing the local cache of events)
Alice can no longer see her conversation with Bob, because we didn't back-paginate past the events from Charlie.
I would have thought this is the same problem as how to handle backpagination in a room with lots of invisible messages (e.g. LLS beacon updates) - so we need to solve it whatever.
My suggestion would be that it tries to backpaginate in N messages (where N=100 or so) and gives up if they're all invisible... but then if the user explicitly overscrolls, it shows a spinner and does another 100. and so the user would have to keep manually overscrolling to get back into visible content.
Our first pass on fixing "pre-join UTDs" (#2317) focussed on identifying such events, and changed the message shown on screen for such error cases.
For example:
However, this remains an unsatisfactory user experience. It would be better to hide such events altogether.
The text was updated successfully, but these errors were encountered: