Notification is posted for a message received while its conversation is open on screen

[levinium]

Checklist

• I can reproduce the bug with the latest version.
• I made sure that there are no existing issues - open or closed - to which I could contribute my information.
• I made sure that there are no existing discussions - open or closed - to which I could contribute my information.
• I have read the FAQs inside the app (Menu -> About -> FAQs) and my problem isn't listed.
• I have taken the time to fill in all the required details.
• This issue contains only one bug.
• I have read and understood the contribution guidelines.

Affected app version

1.9.1

Affected Android/Custom ROM version

Android 17 / GrapheneOS (build 2026091001)

Affected device model

Pixel 10 Pro XL

How did you install the app?

F-Droid / IzzyOnDroid

Steps to reproduce the bug

1. Open a conversation and stay in it, scrolled to the bottom.
2. Receive an SMS in that same conversation.
3. Pull down the notification shade.

Expected behavior

No notification for a message that is already visible on screen. The message was read as it arrived, so there should be nothing left to dismiss.

Actual behavior

A notification is posted for the message and has to be dismissed by hand, even though the conversation was open and the message was visible the whole time. The conversation also stays marked as unread in the conversations list until it is left and reopened.

For anyone in an active back-and-forth, this means dismissing a notification for every incoming message in the chat they are currently typing in.

Additional information

ThreadActivity.refreshMessages() does try to handle this - it calls notificationManager.cancel(threadId.hashCode()) when isActivityVisible. But that runs from the RefreshMessages EventBus subscriber, which is ThreadMode.ASYNC, while SmsReceiver.handleMessageSync() calls refreshMessages() and then showReceivedMessageNotification() immediately afterwards. The cancel therefore usually runs before the notification is posted and has no effect. MmsReceiver posts the notification before calling refreshMessages() at all.

Suppressing the notification at the source rather than cancelling it afterwards avoids the race. I have a working fix for this and would be glad to open a PR if this gets the help wanted label.

[levinium]

The fix is ready on a branch if it is useful for triage:

main...levinium:Messages:fix/skip-notification-in-open-conversation

It skips posting the notification at the source rather than cancelling it afterwards, which removes the race described above. Deliberately narrow in scope:

• Only a conversation scrolled to its end counts as showing the message. Scrolled up, it still notifies, and scrolling down to the message then dismisses the notification and marks it read.
• The alert the notification would have played is played in its place, through the conversation's own notification channel, honoring Do Not Disturb and the ringer mode - so nothing arrives silently and a muted conversation stays muted.
• The conversation shortcut is still created and its usage reported, which previously only happened as a side effect of posting the notification.

assembleFossDebug, detekt and lintFossDebug all pass. Tested on a Pixel 10 Pro XL, with the keyboard open and closed, scrolled to the bottom and scrolled up, and in silent and vibrate modes.

I am not opening a PR since the issue is not labeled help wanted. If you would rather this were behind a setting, or scoped differently, I am glad to adjust it.