Difficult to avoid messages getting marked as read #10886
Comments
|
Another one of these I noticed today: When I have my private messages selected, the list of people who I have PMs with goes off the screen, and I cannot scroll down (possibly a separate bug? edit: #1991). So to see anything that isn't a private message, I have to click "all messages", which marks my oldest unread message as read (really not what I want). I guess I could also either close zulip and open the main page again, or type |
|
@WesleyAC thanks for the feedback, it's helpful! The reason we originally designed Zulip this way was for consistency -- if you click on a stream where all the messages ever sent are unread, for example, we have no message to highlight. I think it was a mistake, but inconsistent behavior leads to its own problems, and at least the current behavior is consistent and correct. I have been planning to eventually move Zulip to "highlight last read message", but that model adds some significant complexity (e.g. in places with only unread messages, in order to achieve this, we need a way to have the selected message be in a special area off the top of the feed, even if there are unread messages present). This is a larger project which is unlikely to happen without a skilled contributor motivated to make it happen; the key piece that would unblock my spending time on this transition is someone doing the work to make having the selection on the top-of-feed area (the thing with the black "Z") work. (A potential semi-workaround is to star messages you didn't want marked read, but obviously that's not a happy solution.) |
timabbott
added
priority: high
difficult
|
Completely agree with your characterization of the problem!
This is my favorite solution so far. |
|
Thanks for the response, @timabbott! Great to hear that this is being thought about and worked on, and I appreciate the context on why this is difficult :) Regarding the solution of making the main page more like the mobile version - is that something that is more feasible? Should I create a separate bug for that? Thanks! |
|
There's definitely an issue around somewhere for that, and it's also on our potentially high-value large projects radar, so need to do that. |
|
Here's another experience that falls under this issue's title: Search resultsWhen I do a search, I'm typically looking for a specific old conversation I have in mind. But if I have unread messages and some of them happen to match the search query, they show up in the results... and then scrolling through the results to find the conversation I want goes and marks those messages read, which may be scattered across a wide range of different conversations. If I don't want to risk completely losing those conversations (i.e. never becoming aware of them, because they got marked as read before I looked at them), this means I have to carefully inspect all the messages I'm scrolling past, watching for unread markers, making sure to spot them before they disappear. Doing that is pretty much incompatible with a high-quality search experience -- I'm spending more effort preventing the search flow from causing me data loss than I am actually looking at the results I was looking for. The simplest fix would be to make a search narrow simply not cause messages to get marked as read. I think I do pretty much never want messages to get read by virtue of seeing them in search results -- I only ever want that when reading in a more coherently threaded context. Not sure what to do about showing unread-markers (which then don't go away, unlike in other narrows), or not showing them (making it look like they're all already read, which could be misleading or confusing.) |
|
Agreed that we should just not mark messages as read in search. |
|
Is it worth opening another issue for "don't mark messages as read in search"? That and mobile unreads view can be independent efforts. |
Hmm, I'd say that answering that question, and then acting to make the issue tracker be the way you think it best for it to be, sounds like something you should feel empowered to just do. 😉 In any case, I went and cloned that bit as a new issue: #12556
Do you perhaps want to have an issue for that effort, too? (Or find an existing one and link it here?) An earlier comment asked about that, too:
This issue's title and description are about a problem, not a solution, and I count at least three different solutions discussed above for different aspects of the problem. If you want to turn this into the thread for that particular solution, that's also up to you, but I'd recommend making that explicit. |
|
For mobile unreads view, there's #11994 open. |
|
See also #12518 |
|
I would also find an improvement in this behavior very useful for my organization, particularly with private messages. Clicking on "Private messages" should not mark any messages as read - as noted above this allows you to leave a certain conversation as unread until you are able to respond to it, but continue to respond to a different conversation that is in progress. |
|
I have another important use case to add to this ticket - if a user has the Zulip window maximized on a high resolution display and has unread private messages from several users (e.g. more than 3 different users), clicking on "Private messages" causes ALL of the messages from all of the users to immediately be marked as read (because the display happens to be large enough to display all of them at once). This makes it very difficult to note which users had unread messages that you now need to review or to selectively choose to look at some of them now but not others. I confirmed that if you make the Zulip window smaller, this behavior does not occur. Can this behavior be changed as part of this ticket, e.g. would the "highlight last read message" behavior mentioned above cause it to NOT mark any of these messages as read? |
|
Another use case to add - with Zulip in the foreground, it will often automatically scroll down and mark messages as read when the Windows computer is locked, which is undesirable |
That certainly shouldn't happen! The logic is very carefully written to not scroll down more than a screen without user input. My guess is there's some sort of bug that's triggering a "scroll_to_end" event, potentially a resize event triggered by a change of monitor or similar, if one's only seeing it on lock/unlock? |
|
This is definitely a major issue for me, and the opposite of “don’t miss an important conversation” selling point of Zulip. I think the best way to fix it would be — to mark messages automatically as read only when I am inside an individual topic (or PM conversation), when I have the whole context of discussion. When I am in an “all messages” view, or when I am in a “stream” view, or in “search” view, no messages should be marked as read. What if I read a non-active stream as a whole, should I enter each topic to mark messages as read? No, below all messages there should be a button “mark all topics as read” — to confirm that I indeed read all of the topics above. I think this behavior would be very consistent, and would reinforce Zulip’s strengths in supporting long asynchronous conversations. |
|
I think this is certainly viable as an option. I'd to some extent to prefer to focus on the solution of taking you to the last read message rather than the first unread, which I think @ryanreh99 was doing some work on, but it could be sensible to do both. |
|
I've noticed this problem recently where I'll be viewing a different message (e.g. typing a private message to User A) and a private message from User B will come in and I'll see it show up grayed out at the bottom of the window. I do not want to read it now as I need to finish what I was typing to User A, so I finish doing that and send the message. Later, I notice that the message from User B has already been marked as read and I've forgotten about it since it did not stay as unread (I would normally click |
For narrows where we select the first unread message on activation, we also `force_rerender` the message list which causes the message to get reselected. Thus when the `MessageList.select_id` is called for the first time, `previously_selected` is -1. However, due to this rerender on selecting the message again the previously selected message and our to be selected message is the same. On passing this information to the `message_selected.zulip` event, the event handler in `message_scroll.js` tries to mark the message as read. The message is marked on the second event instead of the first as the previously selected message is -1. Fixes zulip#10886.
For narrows where we select the first unread message, on activation we have to select it. And on our initial selection was also `force_rerender` the message list which causes the message to get reselected. When `MessageList.select_id` is called for the first time, `previously_selected_id` is -1. However, because the rerender function call is before the event trigger, `select_id` is called again this time with `previously_selected_id` have the same id as the to be selected message and this selection event gets triggered before our first time's selection. This above case only occurs only for narrow activation or when a message is selected again by clicking on it (message is already read for this case). For the All Messages view we have similar logic where, since opts does not contain `force_rerender` we pass `mark_read` as false (which was previously unused) which skips the "message_selected.zulip" event in `message_scroll.js`. Fixes zulip#10886.
For narrows where we select the first unread message, on activation we have to select it. And on our initial selection was also `force_rerender` the message list which causes the message to get reselected. When `MessageList.select_id` is called for the first time, `previously_selected_id` is -1. However, because the rerender function call is before the event trigger, `select_id` is called again this time with `previously_selected_id` have the same id as the to be selected message and this selection event gets triggered before our first time's selection. This above case only occurs only for narrow activation or when a message is selected again by clicking on it (message is already read for this case). For the All Messages view we have similar logic where, since opts does not contain `force_rerender` we pass `mark_read` as false (which was previously unused) which skips the "message_selected.zulip" event in `message_scroll.js`. Fixes zulip#10886.
|
A bit late in the discussion but it seems relevant here: I addressed the same problem in my question in the Zulip community when it was answered by @showell with a rewrite of calc_can_mark_messages_read() in static/js/filter.js. |
timabbott
added
the
post release
On activating a narrow we always mark the first message it selects
as read, which is usually the first unread message. This behaviour
is unwanted.
The flow is as follows:
* On activating the narrow we call the `MessageList.select_id`
method along with a `force_rerender` param.
Here event = {
id: X,
previously_selected_id: -1,
...
}
where X = the first unread message id to be selected.
* Due to this `force_rerender` field, we first call the
`rerender` method and then trigger our custom event handler
(`message_selected.zulip`) which is responsible for marking
message as read.
* However, due to this call path: `this.select_id` >
`this.rerender` > `this.rerender_view` > `this.redo_selection`
> `this.select_id`, the `message_selected.zulip` event gets
triggered with event as = {
id: X,
previously_selected_id: X,
...
}
* Thus the second selection event gets triggered before the
first one having the current and previous id equal to "X".
This above `id = previously_selected_id` consition only occurs
for narrow activation (due to the `force_rerender` flag) or
when a message is selected again by clicking on it (message
is already read in this case).
For the All Messages view we have similar logic where, we pass
`mark_read` as false (which was previously unused) which skips
the "message_selected.zulip" event in `message_scroll.js`.
Work towards zulip#10886.
This is a problem I ran into quite often the last weeks. :) So indeed it'd be great to find some solution here. Only marking messages as read in the per-topic view sounds good to me, but will probably be surprising to some people. |
|
I often miss messages because I have a tab left open in zulip on private messages but I am away. When the tab is not a foreground, but I have selected the private conversation with someone, the messages received on this conversation are automatically marked as read. Looking at the source code, I see no mention of I don't get this kind of issues in Slack, but I don't know what they do differently. |
|
The three items in the original issue description have all been fixed:
Thanks @WesleyAC for raising them! It seems we lost track of this thread and didn't cross-reference it when we made those changes. I believe the latter two happened sometime in the last year or so, but I don't see them in the Zulip Server 7 or Zulip Server 6 release blog posts, so I'm not sure when they happened. Anyway, closing now.
Yeah. @vincentbernat this would be good to file as its own fresh issue. |
|
Noting here that interleaved views will (should) mark the first message as unread unless the user has changed their display setting for automatically marking messages as read: https://zulip.com/help/marking-messages-as-read#configure-whether-messages-are-automatically-marked-as-read. There is an issue where the mark as read automatically behavior is inconsistent: #26021. |
Hmm, I see — thanks for catching that. I guess this should stay open, then. I've set that setting and therefore have not encountered this problem in some time 🙂 @vincentbernat the behavior you described would still be good to file as its own fresh issue. |
Cannot confirm. When I click a stream, the "unread" counter decrements by one. When I then scroll around more messages are marked as read. So it is still hard to navigate streams while preserving "unread" state. EDIT: Ah, I found "automatically mark as read - conversations". That seems to help. :) |
|
Yes, to be clear, there is now (in Zulip 7.0 release) a per-user setting that allows users to set when messages are automatically marked as read. The options are:
Here's the documentation for marking messages as read in the help center: https://zulip.com/help/marking-messages-as-read. It's noted in the Zulip 7.0 blog post under the Release highlights / New and improved workflows section. While existing Zulip users will have to go in and configure this setting, organization admins can set this as the default for new users joining the organization (if they want to); see configure default settings for new users documentation. I agree that the pinned tab marking messages as read should be reported as a separate issue. I'll note that that issue might be fixed by the work I'm doing to fix #26021. I don't know if this issue should remain open as the "per-user" setting does allow the control to not mark messages in interleaved views as read. |
|
I think as long as the default settings are giving people this experience, the problem is still present and the issue should remain open. Specifically, one of the three items in the original report still applies, namely "Streams with unread messages":
That is a pretty common thing to want to do, so I think this is still a significant issue for many users who haven't discovered the setting. (On default settings, if you specifically go to the "All messages" view or the interleaved-DMs view, those will also start marking messages as read. But because "All messages" was replaced as the default view by "Recent conversations", and because clicking "Direct messages" in the left sidebar to try to navigate to the DM you just got now just opens a section in the left sidebar and doesn't navigate to an interleaved view, I think those two UX problems from the original report have been solved.) |
laurynmm
added
area: message feed (scrolling)
|
A few major changes impact this issue:
I'm closing this as I believe all of the core bugs tracked here are fixed, and if there are other bugs/regressions in this area, they probably deserve their own issues, where it'll be easy to focus on those specific problems without the clutter of 6 years of discussion about problems that have now been fixed. Thanks for all the feedback and investigation on this, folks, it's been really helpful! |
|
Yes, things have improved a lot here, thanks for all the hard work. :)
Doesn't that still mark messages as read in the first topic? I have switched the setting to "open channel" immediately to avoid exactly that. (I also have things set up so that the channel view does not mark things as read.) |
|
Yeah, it still marks the top message as read. #30405 is our intended solution for that. It will also mark the whole topic as read if you can see the bottom, but I'm not sure if there's a change that would improve upon that? Also note that you can now turn off messages automatically getting marked as read altogether. |
As I said, having clicking the channel open the channel view together with marking as read "only in conversations" seems like the best option to me in terms of avoiding accidental marking-as-read. |
|
Ah, makes sense. Yeah, while we aren't making that the default, it sounds like that configuration will work well for you. :) |
There are several things about Zulip's UI that make it hard to avoid messages getting marked as read (or at least, make it feel this way - I am unsure of the exact semantics of marking messages as read). This is related to, but distinct from #5462 and #2676. Specific problems that I have:
Main page/All messages UI
When I load the main page, it defaults to the "All messages". At first, I thought that this loaded the next unread message. This is incorrect - it loads the last read message, AFAICT. However, if I inadvertently scroll down on the main page, it will being to mark messages as "read". This forces me to either read them then (often without the context I want), or to ignore them, and risk missing things.
Fix:
Either by default or with an option, replace the main page with a page that shows something more like the mobile Zulip default view. That is, a list of all streams with unread messages, and the title of all topics in each stream (with the number of unread messages next to it). This solves two problems:
I don't know anyone who finds the "All Messages" view useful, and loading it stresses me out due to the number of times I've inadvertently scrolled and marked a message as read by mistake.
Streams with unread messages
Clicking on a stream on the left hand navbar results in a message from that stream getting marked as read. AFAICT, it's the oldest message, which makes this worse - I often have things that I want to respond to, but need to spend a fair amount of time on, so I keep them unread. Once that becomes the oldest thing in a stream, I can no longer click on the stream in the left hand nav, because doing so will result in the topic or message that I want to reply to being marked as read.
Fix:
By default, highlight the most recent read message when clicking on a stream in the left hand nav. Add an option to make clicking on a stream leave the main view blank, but show the list of topic names in the stream.
Private messages
When someone sends me a private message while I have unread private messages, IIRC clicking "Private Messages" on the left nav will mark my oldest private message as read. This is often undesirable. The workflow that I have now is - if I have unread PMs and see that someone has sent me a PM (but I want to leave the old PMs unread), I look at who sent me the message in the popup notification, and search for their name on the right hand nav and click on it, so that it will narrow to just that PM. This is not a great workflow, particularly when I didn't notice the notification, and need to scroll through the entire right nav to see who has a number badge next to their name.
Fix:
Clicking on "Private Messages" in the left nav should highlight the last read message not the last unread message. Additionally, there should be an option to make clicking "Private Messages" show nothing in the main page, but instead simply expand the list of recent people. I would vastly prefer this UI, but understand that it might annoy some people, hence the suggestion for an option.
The text was updated successfully, but these errors were encountered: