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.

Sign up for GitHub

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

Jump to bottom

Old private messages are marked as read without any user interaction #16986

Open
WesleyAC opened this issue Dec 29, 2020 · 2 comments
Open

Old private messages are marked as read without any user interaction #16986

WesleyAC opened this issue Dec 29, 2020 · 2 comments
Labels
area: message feed (scrolling) Scroll behavior, performance, and side-effects (marking as read) bug needs reproducer

Comments

@WesleyAC
Copy link
Contributor

After some amount of time (usually a few weeks or months), private messages are marked as read without any user interaction. This appears in both web and mobile. The messages are subtracted from the unread count, and when I go to the narrow of PMs with that person, the messages are not shown with a blue bar on the left fading away, as I would expect if the messages were being marked as read when I opened the message.

This appears to happen in chronological order (that is, if I have 4 unread PMs from different people, the oldest ones will disappear first).
@adi-001
Copy link

adi-001 commented Dec 31, 2020

Same happened w/me too

@timabbott
Copy link
Sponsor Member

One theory is that this is a side effect of #10886, potentially along with Zulip windows reloading when new messages appear -- we might eat your oldest unread message due to a background reload corner case, and these happen to be PMs.

I attempted to test this theory as follows, without luck:

  • I tried using reload.initiate -- the mechanism through which Zulip reloads content after a server upgrade. Our logic correctly preserves one's scroll position and did not mark anything as read.
  • I tried Ctrl+R browser reloads while viewing "All messages" view. This also did not mark anything as read, though it did select the first unread message, so I imagine further interaction would have marked the first message as read.
  • I tried using the browser's "Reopen closed tabs" feature, same result as the previous one.

Ideas of further possibly low-frequency workflows would be appreciated. But possibly we may accidentally fix this when we resolved #10886.

@timabbott timabbott mentioned this issue Jul 23, 2021
Open
timabbott added a commit to showell/zulip that referenced this issue Sep 23, 2022
@timabbott
message_list: Fix messages marked as read during rendering.
0c2a164 
I found a highly reproducible bug using the "Mark as unread" feature,
which triggers a rerender via message_list.rerender_view().

The reproducer was as follows:
* Navigate to a narrow by going to All messages and using the `S` hotkey.
* Mark as unread to mark several messages as unread in that view.
* Notice that the message that had been selected in home_message_list
  is immediately marked as read again.

What was happening is that the reselect_selected_id call for
message_lists.home (All messages) was incorrectly re-marking the
currently selected message as read, even though (1) that view was not
visible and (2) this was an internal rendering change that could not
be the first time the message was selected.

Because only the current message_list has marking messages as read
blocked, it's still able to mark the currently selected message as
read.

All the callers of reselect_selected_id are internal rendering code
paths that are not intended to be user-visible; as a result, they
should not change the unread state either.

The bug fixed here is a potential root cause of zulip#16986, but I haven't
had a chacne to confirm it.
timabbott added a commit to showell/zulip that referenced this issue Sep 23, 2022
@timabbott
message_list: Fix messages marked as read during rendering.
dd50669 
I found a highly reproducible bug using the "Mark as unread" feature,
which triggers a rerender via message_list.rerender_view().

The reproducer was as follows:
* Navigate to a narrow by going to All messages and using the `S` hotkey.
* Mark as unread to mark several messages as unread in that view.
* Notice that the message that had been selected in home_message_list
  is immediately marked as read again.

What was happening is that the reselect_selected_id call for
message_lists.home (All messages) was incorrectly re-marking the
currently selected message as read, even though (1) that view was not
visible and (2) this was an internal rendering change that could not
be the first time the message was selected.

Because only the current message_list has marking messages as read
blocked, it's still able to mark the currently selected message as
read.

All the callers of reselect_selected_id are internal rendering code
paths that are not intended to be user-visible; as a result, they
should not change the unread state either.

The bug fixed here is a potential root cause of zulip#16986, but I haven't
had a chacne to confirm it.
timabbott added a commit that referenced this issue Sep 23, 2022
@timabbott
message_list: Fix messages marked as read during rendering.
e7b97e2 
I found a highly reproducible bug using the "Mark as unread" feature,
which triggers a rerender via message_list.rerender_view().

The reproducer was as follows:
* Navigate to a narrow by going to All messages and using the `S` hotkey.
* Mark as unread to mark several messages as unread in that view.
* Notice that the message that had been selected in home_message_list
  is immediately marked as read again.

What was happening is that the reselect_selected_id call for
message_lists.home (All messages) was incorrectly re-marking the
currently selected message as read, even though (1) that view was not
visible and (2) this was an internal rendering change that could not
be the first time the message was selected.

Because only the current message_list has marking messages as read
blocked, it's still able to mark the currently selected message as
read.

All the callers of reselect_selected_id are internal rendering code
paths that are not intended to be user-visible; as a result, they
should not change the unread state either.

The bug fixed here is a potential root cause of #16986, but I haven't
had a chacne to confirm it.
@timabbott timabbott mentioned this issue Jul 2, 2023
Open
12 tasks
@laurynmm laurynmm added area: message feed (scrolling) Scroll behavior, performance, and side-effects (marking as read) and removed area: message feed (uncategorized) labels Sep 19, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
area: message feed (scrolling) Scroll behavior, performance, and side-effects (marking as read) bug needs reproducer
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@timabbott @WesleyAC @adi-001 @laurynmm