Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Room appears unread when receiving hidden events - RR not sent #4947

Closed
Tracked by #3363
lukebarnard1 opened this issue Aug 31, 2017 · 4 comments
Closed
Tracked by #3363

Room appears unread when receiving hidden events - RR not sent #4947

lukebarnard1 opened this issue Aug 31, 2017 · 4 comments
Labels
O-Uncommon Most users are unlikely to come across this or unexpected workflow S-Major Severely degrades major functionality or product features, with no satisfactory workaround S-Tolerable Low/no impact on users T-Defect Z-FTUE-Notifications

Comments

@lukebarnard1
Copy link
Contributor

To reproduce (with difficulty), the following steps can be taken:

  1. Disable avatar/displayname changes.
  2. Receive avatar/displayname changes in a room that is:
    a. not active (i.e. no visible events being added);
    b. hasn't been swapped to since the app was refreshed (i.e. hasn't been paginated, has few events in memory and those events are not being shown).
  3. Observe that the room tile is bold.
  4. View the room, swap to another room.
  5. Refresh.
  6. Go back 3 instructions.

The problem is that the RR (Read Receipt) is not being sent for the room because the only events that would normally qualify are hidden. This is fine for RRs in general and reflects accurately what is happening in a room and who can see what events.

The assumption being made is the following: If the RR is not pointing to an event in memory, this room can be considered unread.

This assumption if broken when all events in memory are hidden events.

@lampholder lampholder added T-Defect S-Tolerable Low/no impact on users S-Major Severely degrades major functionality or product features, with no satisfactory workaround P1 ui/ux labels Sep 5, 2017
@lukebarnard1
Copy link
Contributor Author

The solution here is to only indicate new events when said events that are visible in the timeline. If there are none of these, don't make the room tile bold or show unread events.

@t3chguy
Copy link
Member

t3chguy commented Jul 12, 2020

This will be inherently fixed by FTUE Notifications which changes how unread state works

@ghost
Copy link

ghost commented Feb 24, 2022

This is still an issue, and an issue on mobile as per element-hq/element-android#5351

I'm not sure what "inherently fixed by FTUE notifications" means, but if it's been nearly two years since that plan and five with this issue being present, maybe a temporary shorter term solution should be implemented?

@andybalaam
Copy link
Contributor

I think this is a duplicate of #10954 . Please reopen if it's not.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
O-Uncommon Most users are unlikely to come across this or unexpected workflow S-Major Severely degrades major functionality or product features, with no satisfactory workaround S-Tolerable Low/no impact on users T-Defect Z-FTUE-Notifications
Projects
None yet
Development

No branches or pull requests

6 participants