New message marker (fully_read) is frequently at wrong location

[marwing]

Steps to reproduce

1. open room
2. scroll up until new marker is visible
3. notice you didn't see the messages above yet

Outcome

With the following account data according to EW dev tools:

{
  "type": "m.fully_read",
  "content": {
    "event_id": "$Kbh_MizSVNbR_tetg-rTu7Zk3B1-xiGOZkm4gwdNFy4"
  }
}

What did you expect?

Marker directly below the event stored in m.fully_read room account data or the last visible one. In this case this would be above the "Hello!" from Linux Renaissance. The pointed to event is an m.room.member event.

What happened instead?

Your phone model

iPhone 13 mini

Operating system version

iOS 18.5

Application version

25.06.2 (172)

Homeserver

Synapse 1.131.0

Will you send logs?

Yes

[marwing]

I tried but failed to send logs (see #4185 for details). If you need logs for this, please let me know and I'll try to find and send them manually somehow (I'd like to avoid posting them publicly), or fix #4185 and I'll send them in-app.

[stefanceriu]

From my own testing element web seems to move the fully read marker (with some sort of delay) to the bottom of the timeline as you scroll through it and Element X updates accordingly.

I would argue the behavior is wrong as it should set it to the top of the timeline while scrolling, until the bottom is reached and then mark the room as fully read.

I'll have a look at https://github.com/element-hq/element-x-ios/issues/4185 but there's slim chances logs would help here, too many moving parts to track correctly.

[marwing]

I would likely agree with your argument, particularly in light of https://github.com/element-hq/element-x-ios/issues/4177, which, if I interpret it correctly, breaks partially reading a room worse than it was before (something I'm going to test with the new nightly build). The issue here, though, is that the room wasn't opened in EW before opening it in EX, and therefore the marker is indeed displayed at the wrong location. This has also happened with way more than three visible messages between the expected and actual marker positions.

Thanks for taking a look. In this case, I'll hold off on sending logs for now.

[pixlwave]

Fixed by #4177.

[marwing]

This was not actually fixed, I just verified with the nightly TF build. The issue is that the marker is rendered at the wrong location (some messages newer than it should be) according the the fully read marker in the room account data, not that that account data isn't updated. If I had to guess, I'd say the sdk timeline inserts it at the wrong location for some reason.

I also found the marker missing if it would have been between collapsed state events. This is likely not an sdk issue, as I can see it in a different rust sdk ui based client (using the current 0.12.0 release of the sdk).

[pixlwave]

My bad, sorry @marwing, I'll re-open this issue.