Bulk-mark-as-read button is often unresponsive

[WesleyAC]

The "Mark stream as read" button sometimes appears to do nothing on being pressed for a long period of time. Ideally, the bar should disappear immediately, instead of blocking on the response from the server. It's important while doing this to make sure that the unread info will get synced to the server eventually, even if the user closes and reopens the app, etc. The thing to avoid is the experience of not caring about a stream, clicking "Mark stream as read", and then needing to wait around for many seconds staring at a stream the user isn't interested in while waiting for the "N unread messages" banner to go away, worried that if you go away then, the stream won't be marked as read.

I haven't looked at the current implementation in enough detail to know what the actual behavior of it is, other than what I can easily see as a user, so I don't know how much work this is. It could be as easy as switching the data source for the unread bar, or as difficult as making a fully functional "offline mode".

@gnprice, do you have an idea of how much work is involved here?

[chrisbobbe]

I'm on mobile right now, but linking #3549 which looks like it might be related. :)

[gnprice]

For the current implementation of this, see MarkUnreadButton.js. What's happening is that we immediately fire off a request to the server to mark the stream (or topic, etc.) as read; but the button is always there when its enclosing banner is, and that's controlled by our local state of which messages are read. Which we only update when we get an event from the server saying the messages were marked as read.

If you mark a lot of history as read, that will take some time for the server to process, and it'll be a while before we get that/those events. Plus there's some latency in going to the server and back (even when it's just a few messages and quick for the server to handle) -- that's the part #3549 is about.

In the webapp the behavior is actually pretty similar to what you describe -- when I mark a whole stream as read (which I occasionally do for some stream I've muted where I have many thousands of unreads), it'll sit for some seconds not obviously doing anything, before the unreads go away. It isn't excellent there either.

I think for making the "N unread messages" bar disappear immediately, we'd also want to make everything else in the app reflect that those messages were no longer unread -- the green "unread" bars in the message list, the unreads list in the home screen, etc. Which basically means doing #3549. I think we'd want to be sure to retry the request if we were doing that, like you say:

It's important while doing this to make sure that the unread info will get synced to the server eventually, even if the user closes and reopens the app, etc.

There isn't really an existing infrastructure to just plug into for that (we do retries for sending messages, but that code is ad hoc and not very reliable at its current job -- see #3881 and #3829), so this wouldn't be a simple task.

For this particular bit of user experience, one immediate thing we could do that would probably be an improvement is to at least signal clearly that something is happening, i.e. that touching the button didn't just fail to do anything. A natural way to do that would be to replace the button, or its label, with a spinner.

[chrisbobbe]

We got another report of this today, but with "Mark all as read" instead of "Mark stream as read". I just changed the title because I expect this to affect all bulk-mark-as-read buttons, not just the one for streams.