STR: 0. prerequisite: have a big conversation, different from the one where you'll receive the messages in this bug. 1. Send a message to the device, in a position so that you'll get a notification (so don't be in the conversation you're receiving the message from). 2. open the big conversation. 3. Quickly tap the received notification. => Notice you get messages from both the big conversation and the received message's conversation. I got at least one report from a dogfooder. I don't know if it's a regression (let's ask QA :) ) but I'm sure we should fix this.

Hi Julien, do you have more info like where to be when receiving the sms if the app is open, or if the app is in background, closed...Also, how big should be the conversation more or less? I am trying following the steps in the description with a conversation with 20 messages, and trying with different scenarios but so far after tapping on the notification, once the long conversation is open, the message is shown only in the correct thread. Will keep trying. Thanks

(In reply to Isabel Rios from comment #1) > Hi Julien, do you have more info like where to be when receiving the sms if > the app is open, or if the app is in background, closed... From my tests this has no importance. > Also, how big > should be the conversation more or less? > > I am trying following the steps in the description with a conversation with > 20 messages, and trying with different scenarios but so far after tapping on > the notification, once the long conversation is open, the message is shown > only in the correct thread. Will keep trying. You definitely need more than 20 messages :) You can try pushing a big database using the command "make reference-workload-high" from the Gaia directory. Then you'll have 3 big threads that you'll recognize easily from their names.

(In reply to Julien Wajsberg [:julienw] from comment #2) > (In reply to Isabel Rios from comment #1) > > Hi Julien, do you have more info like where to be when receiving the sms if > > the app is open, or if the app is in background, closed... > > From my tests this has no importance. The issue is that we continue to feed the displayed view with messages from the previous conversation even than we changed the conversation. We already have a function that stops the current rendering, but it's currently used only when the user presses the "back" button. I think we simply needs to move the call to beforeLeave (or maybe have it at both places). So it should be a really simple fix.

Finally I could reproduce the issue both in Aries 2.5 and Flame 2.2 so this does not look like a regression but I agree with you that this should be fixed. Attached two screenshots about the problem. The header of the message shows the sender number, but the thread is mixed up with with the big thread message.

I can take this bug now.

Triage: blocking

Comment 4 answered the qawanted question.

Comment on attachment 8680521 [details] [gaia] julienw:fix-stop-rendering-notifications > mozilla-b2g:master Hey Oleg, what do you think of this change ? :)

Comment on attachment 8680521 [details] [gaia] julienw:fix-stop-rendering-notifications > mozilla-b2g:master Looks good to me, just some questions regarding integration test - I think we can make it closer to the conditions in which issue appears in real life.

Comment on attachment 8680521 [details] [gaia] julienw:fix-stop-rendering-notifications > mozilla-b2g:master hey Oleg, I think I fixed the issues you outlined in your first review. I've put the changes in a separate commit for an easier review :)

Comment on attachment 8680521 [details] [gaia] julienw:fix-stop-rendering-notifications > mozilla-b2g:master LGTM, thanks for the brand new integration test! I've run relevant Gij 16 15+ more times - and everything is green :)

master: ef8d5801f34219d7162415f56e6811a0e7cae305 thanks for the review !