"Jump to first unread message" (read marker) is often wildly incorrect

[jdm]

Description

When I read through the latest messages in a room in the Mozilla Riot instance, then close the tab and later reopen it and visit that room again, pressing the "Jump to first unread message" takes me back multiple days in the room history that I have already read.

Steps to reproduce

• Visit a root in the Mozilla Riot instance (such as the DOM room)
• Read all the newest messages of the room.
• Click another room (Servo), read some more, then close the tab.
• Open the Mozilla Riot instance tab once more and visit the DOM room once there are new unread messages present.
• Press the "Jump to first unread message" button that appears.

I expect to be taken to the last message that I read. Instead I'm usually taken to messages from several days ago.

It may help to mention that in rooms like DOM I find the "Jump to first unread message" button does not ever seem to go away even when I reach the newest messages in the room.

Logs being sent: yes

Version information

• Platform: web (in-browser)

For the web app:

• Browser: Firefox 74 nightly
• OS: macOS
• URL: https://chat.mozilla.org/

[jdm]

I received advice that it may require several seconds for a room to decide that I've read it. I am currently looking at the Servo room, and I've been talking in the room all afternoon. There's now a "Jump to first unread message" button showing that takes me back several hours, and when I scroll to the bottom and wait for multiple minutes it doesn't go away, even if I switch away to another room and back.

[jryans]

It does seem like something has regressed here. We'll investigate.

[ara4n]

related: #10942

[turt2live]

Largely I think this is indeed a problem with the timers. It might be as simple as changing the values a bit (I find that 2ms works great for me, but obviously not everyone is interested in clearing it as fast as possible).

@vector-im/design will have to take a look at this, possibly with a partial product hat on.

[turt2live]

For additional context:

[jdm]

I don't see how those timers can be causing the issue that I originally reported, which involves me staring at rooms for minutes using the default values.

Edit: unless I'm misunderstanding, and I actually need to be staring at where the "Jump to first unread message" takes me for several seconds?

[turt2live]

I can't reproduce that failure, but I do know the timer stops when the tab isn't focused. If you quite literally click on the room, take your hands away from your input devices, and count to 30 it should go away - this is obviously not ideal, which is why design is being pulled in.

[jdm]

Ok, but that's not what happens for me. I see the button stay present in rooms that I'm actively focused on for minutes at a time.

[turt2live]

hmm, can you try again and send updated logs? I'll try to take a look.

[justdave]

The following I commented in #syncronicity:mozilla.org earlier this week:

ok, with some experimenting, I think I figured out the issue with the read pointers not updating...
every message needs to stay onscreen for as long as your "read marker lifetime" setting is set to
if you scroll past it in the window faster than that, it won't mark it as read
I have mine set to 7 seconds because 3 was disappearing too fast when I focused the window.
and when I'm skimming through scrollback it's pretty easy to read the content of the screen in faster than 7 seconds, especially when passing a section that has lots of link previews and so forth
if you keep an eye on the top right corner of the message pane as you're scrolling, if you go too fast, the green arrow to show an off-screen marker will show up. As soon as that shows up, scroll back up till you see the green bar again, then wait for it to go away, then start scrolling again.
and that'll successfully update the pointers
alternatively, sit at the bottom of the channel for as long as your "offscreen read marker lifetime" setting before going elsewhere (wait for the green arrow to disappear)

However, I've since discovered that the first time I run RiotX it hoses all my pointers again. After running RiotX, my pointers in Riot/desktop went back to the spot they keep jumping to in recent history. So the real problem may be a bad interaction between desktop and riotx/android.

[justdave]

However, I've since discovered that the first time I run RiotX it hoses all my pointers again. After running RiotX, my pointers in Riot/desktop went back to the spot they keep jumping to in recent history. So the real problem may be a bad interaction between desktop and riotx/android.

And I'm not even sure about that anymore, I'm failing to reproduce it purposely interacting between the two. Everything seems to update real time in both directions. So maybe I just had to stay logged out of both overnight to trigger it again? Dunno, it's all weird.

[turt2live]

Something for the design team to consider: #12506

[Standard8]

I've had a similar issue to justdave a couple of times now. I've shutdown the Riot desktop app overnight, read messages on RiotX, and then when I open the desktop app again I hit this:

• The room lists show as read (unless there is actually new messages)
• The unread marker within rooms shows me that I haven't read things since yesterday (or maybe before).

Going into settings -> help and clearing the cache and reloading seems to fix this.

I'm not 100% sure, but I think RiotX isn't always picking up that I've read things on the desktop app as well. It could be happening when it is getting into this bad state.

[Standard8]

I'm back in the state where some channels aren't updating the read status. I'm using the defaults settings.

I look at the room and scroll back to the unread line. I wait for the green line to disappear, then scroll down slowly (if I need to for that room). The green dot at the top does not reappear.

Sometimes I'll wait in the room for more than 30 seconds with Riot focussed, I can even spend a minute or two typing in the room.

I then go to another room, and come back again, and the unread green line status is where it was originally.

I had this a bit earlier today, and did a clear cache and reload, and it didn't reset the unread marks as it had previously.

[jryans]

From what I am reading in the feedback here so far, I don't believe we need design / product guidance here: instead, there's a bug we need to fix.

It's true that the timer-based behaviour can be quite confusing, and we may eventually want a product decision to change that. What I am hearing in this issue though is a bug that goes something like:

1. People are aware of the timers and are waiting until the read marker fades in a room
2. When they switch away and come back to the room, the read marker is back to where it was before

I have observed this happening at various times as well. It seems like clearing the read marker "several" times (watching the green line) seems to make it progress as a workaround, but of course that is quite a bad experience.

[bjherbison]

This is a problem that comes and goes for me. After days of working fine I observed it on Saturday on chat.mozilla.org. The issue resolved itself over the course of Sunday and Monday and is back to normal today. (It seems that after "something" happens the next message in a room will let that room get fixed.) And all along the unread counts seemed to be accurate, even when the pointer was off.

What doesn't work (when the state is bad):

• Sitting for a minute at the unread point with focus on the tab.
• Scrolling slowly through the "unread" messages.
• Shift-refresh with the page.
• Restarting Firefox. (I use Firefox Nightly so I restart for updates twice a day.)

Should I report the problem if I see it again? Is there any useful information to collect?

[jryans]

Should I report the problem if I see it again? Is there any useful information to collect?

Thanks for your experience report above! If you do see it again, feel free to submit debug logs in Riot (Top left menu -> Settings -> Help -> Submit debug logs) and reference this issue.

I do have some theories on what's going wrong here, and I'm hoping to have more to share here soon.

[Standard8]

I've been testing this without the RiotX client running for the last week or so. Generally it feels like the markers behave better, however, towards the middle/end of day, they're getting messed up again.

[Standard8]

Without the RiotX android client this is still behaving badly, and it seems kinda random as to when it gets messed up or not.

Is there any more information I can provide here to help this get resolved?

[jryans]

Thanks for the updates on this, I know this is quite a painful issue once you notice it. 😖

I've been able to reproduce what I believe is the same issue locally. It's a complex area of the app, so the main challenge at the moment has been finding enough time to focus on this. I'll try to block off some time this week to work on it.

[jryans]

Riot 1.6.6 (which is also now deployed to chat.mozilla.org) includes a potential fix for this. @Standard8 @bjherbison @justdave @jdm, please re-test over the next few days of use and let me know if anything might have improved.

[bjherbison]

Thank you, @jryans, Riot 1.6.6 on chat.mozilla.org is behaving much better than the previous versions. I haven't spotted a glitch in the read marker, even when switching between computers.

[justdave]

Haven't noticed any issues lately here...

[jryans]

Thanks everyone for verifying, I'm very happy to hear this is now working for everyone. 😁