In TB 60, when a message arrives in a private chat and the TB chat tab is not current, that is, some mail-related tab is open, I get two notifications:

The chat icon in the toolbar receives a "badge" and the chat tab receives a (N), additionally, when the TB window isn't active, there is a (Windows) notification in a bubble from the systray.

In TB 68 beta (unofficial build), the badge and the (N) in the tab are missing if TB is the current application, a sound is still played however. They still work, when you bring another window forward, like Firefox, an editor, etc.

This makes the chat hard to use, since I need to watch the private chat all the time since notifications are missing :-(

Looks like the code doing the chat notification doesn't notice that chat is no longer the active tab. It does notice that TB is no longer the active window.

OK, I've just noticed that "jorgk: hi there" in #maildev also doesn't notify any more. So personal notifications appear to be broken throughout.

Magnus, this is hard to test alone, should we get together for a few minutes and I'll demonstrate? Or perhaps it's behaving differently on Linux. On Windows, I get a notification if the TB windows is not active, I don't get one when it's active but the chat tab isn't active. I do get a sound though.

(In reply to Jorg K (GMT+2) from comment #1)

Looks like the code doing the chat notification doesn't notice that chat is no longer the active tab. It does notice that TB is no longer the active window.

Indeed. Even if you're working in a compose window, the notifications are coming. As soon as you switch to the main window, but not the chat tab, they stop working. Does anyone know where the code is that looks at the window/tab and suppresses the notification when in the chat tab.

Could it be this: https://searchfox.org/comm-central/rev/7db00200238867751687f2eee2e4f51d34e266dc/mail/components/im/modules/chatNotifications.jsm#127 ?

Yes, it's there, thanks. But I don't understand this code at all.

https://searchfox.org/comm-central/rev/7db00200238867751687f2eee2e4f51d34e266dc/mail/components/im/modules/chatNotifications.jsm#51-55
says that when the 3pane is active, there is no notification (although a sound was played). Well, that's not the behaviour in TB 60. There notifications are shown, if the 3pane is active, but not the chat tab. I see this was changed in bug 1418834 which landed in the 59 cycle:
https://searchfox.org/comm-central/diff/b3ba4bf8d8d2a69a6628e288e5ef9b78f63e0fbd/mail/components/im/modules/chatNotifications.jsm#53

And
https://searchfox.org/comm-central/rev/7db00200238867751687f2eee2e4f51d34e266dc/mail/components/im/modules/chatNotifications.jsm#127
is even more mysterious since this appears to switch to the chat tab. Fortunately this doesn't happen, it would be fatal switching to the chat tab when a message arrives and I'm reading some e-mail.

EDIT: That last bit at line 127 is in the function that runs when the user clicks. So that does make sense.

Other than that, TB 68 behaves like the code says, but I don't think TB 60 behaved that way, with the same code, weird.

This restores the notification if the chat tab isn't active. That's TB 60's behaviour, based on the same code, so I don't understand how it works in TB 60.

With the patch we get three notifications: The buddy badge (apply bug 1538547 first to see it), the count in the chat tab and also a notification bubble, in Windows that comes up from the systray.

TB 60 behaviour is to show the former two, but not the bubble, again, no idea how that worked.

TB 60 code here:
https://dxr.mozilla.org/comm-esr60/source/mail/components/im/modules/chatNotifications.jsm#52

I guess this patch isn't right. It switches on the notification bubble and magically the buddy badge (apply bug 1538547 first to see it), the count in the chat tab appear again that go lost somewhere.

So the question really needs to be: Where are the buddy badge and the count in the chat tab produced? That's the place that broke. This code here is about the bubble notification and it works as designed.

Alice, would you be able to find the regression for us. In order to do that, you need two computers and two instances of TB running. You need two computers since on both machines the TB window needs to be active and have focus (and that can't be done with one machine).

One of the machines can have plain TB 60 installed to send chat messages, the instance on the other machine needs to receive them and that's where you need to try different versions.

If you have two machines, let me know and I'll give you precise STR.

(In reply to Jorg K (GMT+2) from comment #9)

If you have two machines, let me know and I'll give you precise STR.

I have a only one PC.
Is it possible between on TB60(sender) guest OS and TB68+(receiver) host OS of VMWare?

Hmm, I guess, as long as the receiver TB can have an active window in the VM while sending from TB on the real machine from its active window. Or you can come online in a chat and I send you messages when needed. Last night I looked at the issue with two machines, that was easiest.

This is the issue: The receiving TB instance can have multiple tabs, usually the folder tab, and the chat tab. When a message directed to you arrives when you're in the folder tab, you used to see a notification in form of numbers popping up in the chat icon and the chat tab, but that no longer works. It still works if the window of the receiving TB instance is not active.

Florian and Patrick, given that we'll have to ship buddy badges and counts on tabs broken in TB 68 beta 1, it would be good to fix it for beta 2. Can you please point me to the code that updates those. Forcing a notification like in the patch gets those two updated, so I'm a bit puzzled.

I'd also like to clarify the nomenclature here for the three types of notifications:

• What I call "buddy badge" which seems to be the number displayed on the chat icon in the toolbar
• what I call "count on tab", the (NN) number that's displayed on the chat tab
• the notification with the actual (shortened) chat message that pops up from the systray on Windows.

For the bisecting: TB 67 still works, TB 68 doesn't so this regressed during the 68 cycle, 2019-03-11 - 2019-05-13, so we have a regression range of about 64 days, so that should be findable with 6 steps.

2019-04-12: working, 2019-04-27: broken, 2019-04-19: working, 2019-04-23: working, 2019-04-25: working, 2019-04-26: broken.

Last good: be3851b8c6acd9c340c10b278e918ae82cd3ad7e (2019-04-25)
First bad: dc7943c0ecc96b6565b45878a80150944941ac1a (2019-04-26)

https://hg.mozilla.org/comm-central/pushloghtml?fromchange=be3851b8c6acd9c340c10b278e918ae82cd3ad7e&tochange=dc7943c0ecc96b6565b45878a80150944941ac1a

So this looks very much like a regression from bug 1538548 or potentially bug 1534249 which has some JS changes as well:
https://hg.mozilla.org/comm-central/rev/dc7943c0ecc96b6565b45878a80150944941ac1a
https://hg.mozilla.org/comm-central/rev/56e61fde5f623a6004a10867428d056b32d79cb6

It's could also be bug 1536935:
https://hg.mozilla.org/comm-central/rev/9a139533ba44fb8211af54a2a80e02c889263f0a

I'll try some treeherder builds next.

Backing out bug 1538548 fixes the issue. I will consider this for TB 68 beta.

TB 68 beta:
https://hg.mozilla.org/releases/comm-beta/rev/309726191f531ede8c9a7a29546dbeb531dbdad3
Backout bug 1538548 to fix chat buddy badges and tab counts for TB 68 beta. a=backout

Looks like one consequence of the backout is that when switching from the chat tab and back to it, the conversation that was selected before isn't selected any more. So the choice is between a rock and a hard place :-( - So what's worse, no notification or an extra click?

Backout Bug 1538549 and Bug 1538550 from TB 68 beta and tab issue will be resolved. I will resolve the notification issue in TB 69 by the end of this week.

Hmm, I backed out bug 1538548 and the badge/count notifications came back, at the cost of losing the selected chat (see comment #16, comment #17).

On TB 68 beta, in the chat richlistbox, richlistitems are combination of XBL binding(im-conv) and CE(chat-contact and chat-group), so it is not behaving correctly. So it should be all three or none for the correct old behavior.

Yes, works better with more bugs backed out:
https://hg.mozilla.org/releases/comm-beta/rev/f9d71258b6c07e8df91f175a9f8e6a666b32cc92
https://hg.mozilla.org/releases/comm-beta/rev/56312084fa4a75f0b80a4f645b947a7f4328910b

Let's hope we get the "real" fix soon, so this can all go back in.

This is actually FIXED by bug 1538547. Looks like it was due to a strange mix of XBL and de-XBL code.

I'll revert the backouts and land that bug instead on the beta.

I cheered too early. While this issue is fixed on trunk by bug 1538547, reverting the backout of bug 1538548, bug 1538550, bug 1538549 and landing 1538547 instead DOES NOT fix the issue on TB 68 beta.

I still think is the toxic mix of XBL and de-XBL code, the beta is different from trunk by bug 1546332 and that can't be brought forward since it depends on M-C bug 1519514.

So I guess for the beta, we have to go with the backouts. Or does anyone have a better idea?

That sounds ok. Doesn't matter too much to have those as xbl still on 68.

Well, that mix causes problems: Bug 1559097, and bug 1556203 is hard to fix in the XBL world.

Fixed via backouts, see comment #21.