Mobile notifications are not dismissed when reading a message on desktop

[eiclu]

I use Zulip on my phone and on my pc. When I receive a message, a notification appears on my phone. If I then visit the message on my desktop instead of on my phone, the notification stays there even though the message was already seen.

This means that often times when glancing at the phone I will think there is a new message on Zulip, when in reality it's an older message already read by me

[chrisbobbe]

Thanks for the report! Are you on Android or iOS?

If you're on iOS, this feature is tracked in #3119.

[eiclu]

Sorry, I forgot to clarify - I am on Android

[chrisbobbe]

Interesting; I think we've assumed this feature is already working on Android; it was tracked in #2634, which was closed as complete in 2019.

I think the most likely next step for the core team is to implement notifications in our new Flutter app that we're building to replace the current app that's written in React Native: https://github.com/zulip/zulip-flutter/issues?q=is%3Aopen+is%3Aissue+label%3Aa-notifications

When we do that, we should test that notifications get dismissed when messages are read.

[gnprice]

This feature continues to work correctly for me. (I just checked — there was a notification I had on my phone, I went and viewed that conversation on web on my desktop so that it got marked as read, and the notification promptly vanished on my phone.) So it's not just broken in general, and something more specific is going on.

Could you tell us a bit more about your use of Zulip, to help gauge what the nature of the issue might be?

• Are there several different Zulip accounts you get notifications for, or just one?

• Is your Zulip use on Zulip Cloud (zulipchat.com), or is some or all of it on other servers?

• What vendor and model of device are you using?

---

As background, there are two broad areas for where the issue might lie:

• It could be in our code for handling the information the server sends telling us to remove a notification because the message has been read. There are some data structures there, and some interactions with the OS, and we could have a bug in that code. (Or your OS could have a bug or quirk in that code, which we might be able to work around after debugging.)

  If this is where the issue is, then it'll likely get fixed automatically as a consequence of rewriting that code for the Flutter app.

  This is also something we can pretty comprehensively test for.

• It could be that when the server sends the app that information, it's not making it to your device, or the device's OS isn't passing it on to the app. This could happen if the OS decides the app is spending too much time and battery life handling too many of those, or the Google service responsible for delivering push-notification data to devices (Firebase Cloud Messaging, as they currently call it) decides that we're sending too many of them.

  In particular, when you have a new message to show a notification for, the server (following Google's spec for that service) sends that information as "high priority", but when a message you had a notification for gets read, the server sends that information (again following the spec) as "low priority". So potentially the service, or the OS, could be deciding to screen out our "low priority" updates (so that the notifications don't get auto-dismissed) while still delivering the "high priority" (so you continue to get notifications in the first place).

  If this is where the issue is, then it might or might not automatically get fixed as a consequence of the rewrite.

  This is also inherently hard to write effective tests for; it's all about what happens in the field, so user reports like yours are critical.

• Oh and a third: it could be that some server issue is causing the server not to send those updates telling us to remove a notification because the message was read.

  Naturally this would be unaffected by our Flutter rewrite of the mobile client.