Ensure we always show read receipts even with hidden events #3056
Conversation
This changes how we determine read receipts for the entire message panel. We now calculate read receipts for all events up front, which makes it easier to handle hidden events by moving their read receipts up to the last shown event for display purposes. Part of element-hq/element-web#9745
This adds additional receipt storage to so that we can handle cases where the receipts and events lists get out of sync. If we ever find a user who previously had a receipt but momentarily no longer does, we recover their previous receipt and go with that until we hear something new. Part of element-hq/element-web#9745
|
Does this happen to fix element-hq/element-web#5761 (the problem within, not necessarily the solution proposed)? |
Yes, it looks like it should if I understand that issue correctly... If someone has their read receipt at a hidden event, this change will wind that back up to the last displayed event so that it's always shown. |
|
That indeed is the problem, so yay! |
Good question! I don't think account size is the limiting factor, but instead the number of people and events in the current room. Here's some timing info from Matrix HQ:
So, that's not great... 😖 Initial profiling suggests it's less about the existence of loops and more about calling |
|
After further tweaking, we have:
I think that's probably good enough for now. We could optimise further by caching the settings reads in |
Settings is too expensive to query in a hot code path, so this caches the value on the MessagePanel component instead.
For some reason, we were getting the room object for every event during read receipt processing, even though it has been passed in as a prop already.
This work fixes up the display side of read receipts so that we ensure a user's read receipt remains somewhere on the timeline even when
Part of element-hq/element-web#9745
Fixes element-hq/element-web#5761