Element-web: Read receipt animation sometimes has holes in it

[babolivier]

I've observed this using riot.im/develop on Firefox (on GNU/Linux), read receipts sometime display with a hole in the middle:

If I click on the one at the right to expand the list, it expands correctly, and collapse correctly (like it should have been displayed in the first place, without holes) if I click again.

[turt2live]

Usually this is the media repo being slow or unresponsive. Does reloading the page help?

[babolivier]

Usually this is the media repo being slow or unresponsive

I just saw that happen with read receipts from people with no avatar. The issue is that the second read receipt from the right seems to be "hidden" behind the first as when I click the one on the right the second one "slides" from behind it and fix the display.

[babolivier]

Here's one occurrence I managed to catch in the wild:

The animation is triggered by me clicking on the first avatar from the right (unfortunately Peek seems to have troubles capturing my cursor).

[turt2live]

I can say I've only ever seen that behaviour when the media repo has a problem (the image fails to load, and it doesn't fall back to letters, which causes weird merging and artifacts). Some other side effects are read receipts sticking to the wrong events, etc.

Would recommend doing a hard refresh on the page, or opening the inspector, going to network, disabling cache, and refreshing.

[ara4n]

i've seen it even when the media repo is fine. there's been a long-term bug where sometimes the tetris algorithm races and fails, which brendan's screenshot shows (as delph & neilj collide)

[ara4n]

Relatedly, the alignment in general is getting worse and worse - e.g.:

[babolivier]

Apparently still not fixed:

Just witnessed now on latest develop. I saw Half-Shot RR dropping behind Amandine's, and it moved to fill the hole when I clicked on a read receipt.

[uhoreg]

This may also be https://github.com/vector-im/riot-web/issues/3976

[Bubu]

This is basically happening for me constantly. A room switch fixes it, as does clicking the RRs.

Before:

After click:

basically I can never trust RR's without clicking on them. :-/

[turt2live]

This has regressed even further as of ~1 week ago. Previously you could "fix" it by sending events or causing the timeline to update, but now it's stuck as broken until you switch rooms.

[Half-Shot]

Started to notice that even in 1:1 rooms, the read receipt doesn't move until you click away from the room or the other person sends an event. It's almost as bad as not having them enabled at this point, and it really feels like read receipts being horribly inaccurate should be a :fire: and not a P2.

[dbkr]

Looks like this was caused by moving BaseAvatar to hooks in https://github.com/matrix-org/matrix-react-sdk/pull/4101 - it looks like the set if URLs & index are initially defined to be empty / undefined and then subsequently updated, which means BaseAvatar starts out rendering all avatars as the default no-avatar, then updates it to the real avatar immediately afterwards.

This breaks Velocity because it starts out animating the span but then this gets swapped out for an img just after it starts animating it.

We probably ought to:

1. Make BaseAvatar be the right avatar from the start rather than changing its mind
2. Make it handle this more gracefully
3. Wrap the avatar in a common element so there's a consistent thing to animate

2 & 3 are probably better done by killing off the velocity animations in favour of CSS animations. 1. seems like a thing we ought to do anyway because it must be causing quite a few unnecessary updates every time we re-mount a BaseAvatar, but I'm really finding the hook code very hard to read.

[jryans]

For part 1 of fixing this, I agree the control flow seems much harder to follow with hooks... 😖

In more detail, it's not clear to me what a "good" way to compute a complex initial state value before the first render happens, which seems like what we want here to ensure the URL lists are static and unchanging. In a class component, it would be easy to run these steps in the constructor, but I am not sure what the blessed way to do it is for hooks.

[dbkr]

Confirmed that above PR fixes the problem with read receipts not moving down, but this bug seems to represent all manner of symptoms so I'm not going to venture to say this issue is fixed.

[jryans]

Returning this to the backlog for now, as https://github.com/matrix-org/matrix-react-sdk/pull/5142 seems to address the most critical regression. Future work here would likely endeavour to switch to CSS animations.

[babolivier]

I'm still seeing some read receipts not moving down as they should (it's much more rare though), is this expected?

[jryans]

I'm still seeing some read receipts not moving down as they should (it's much more rare though), is this expected?

Yes, that's the known state of the issue at the moment: it should be rare, but still possible.

[Bubu]

it should be rare

I think it is better than before, but I'd call it far from rare. I'm still seeing it for most of the messages for one or two RR avatars in a somewhat busy channel.

Took me about 10 s to wait for an opportunity to grab a screenshot:

[babolivier]

Agreed, I've been seeing it happen quite reliably for the past few weeks, so it's more frequent than rare atm