1893349 - Resolve the 10 seconds delay for native Windows notifications

Status: RESOLVED FIXED

(Thunderbird :: OS Integration, defect, P1)

Description

[Alessandro Castellani [:aleca]]

Native system notifications are completely broken in Windows 11.
I only hear the sound but no notification is shown and code silently fails.
115 is unaffected so something must have changed on the m-c side.

Comment 1

[Alessandro Castellani [:aleca]]

Maybe bug 1805514?
Gentle ping to Nick to see if there's something that we didn't port or we need to adapt.
(These)[https://searchfox.org/comm-central/search?q=%22%40mozilla.org%2Falerts-service%3B1%22&path=mail%2F&case=false&regexp=false] are the instances of alerts-service we use for emails.

Comment 2

[Alessandro Castellani [:aleca]]

To add to this, it seems that the tests run in (browser_notification.js)[] pass but it's not true. The tests are written in a way that they succeed even if the native notification fails.

Running them locally they return green but scrolling a bit back up in the terminal this can be found:

0:15.28 GECKO(29380) console.error: mail.notification: ({})
 0:15.32 INFO Console message: [JavaScript Error: "NS_ERROR_FAILURE: " {file: "chrome://mochitests/content/browser/comm/mail/test/browser/notification/browser_notification.js" line: 50}]
showAlert@chrome://mochitests/content/browser/comm/mail/test/browser/notification/browser_notification.js:50:24
_showAlert@resource:///modules/MailNotificationManager.sys.mjs:351:23
_fillAlertInfo@resource:///modules/MailNotificationManager.sys.mjs:209:10
async*onFolderIntPropertyChanged@resource:///modules/MailNotificationManager.sys.mjs:153:16
addSetsToFolders@resource://testing-common/mailnews/MessageInjection.sys.mjs:690:9
makeNewSetsInFolders@resource://testing-common/mailnews/MessageInjection.sys.mjs:558:16
make_message_sets_in_folders@resource://testing-common/mail/FolderDisplayHelpers.sys.mjs:270:27
make_gradually_newer_sets_in_folder@chrome://mochitests/content/browser/comm/mail/test/browser/notification/browser_notification.js:204:10
test_revert_to_newmailalert@chrome://mochitests/content/browser/comm/mail/test/browser/notification/browser_notification.js:716:9
handleTask@chrome://mochikit/content/browser-test.js:1139:26
_runTaskBasedTest@chrome://mochikit/content/browser-test.js:1211:18
async*Tester_execTest@chrome://mochikit/content/browser-test.js:1353:14
nextTest/<@chrome://mochikit/content/browser-test.js:1128:14
SimpleTest.waitForFocus/<@chrome://mochikit/content/tests/SimpleTest/SimpleTest.js:1058:13

I suspect a lot of things are wrong inside (MailNotificationManager.sys.mjs)[https://searchfox.org/comm-central/source/mailnews/base/src/MailNotificationManager.sys.mjs]

Comment 3

[Alessandro Castellani [:aleca]]

Attachment: Bug 1893349 - Set windows.notificationserver pref to false to temporarily fix 10 seconds delay for Windows notifications. r=#thunderbird-reviewers

Comment 4

[Alessandro Castellani [:aleca]]

Added a WIP patch which at least make our native notification work again, but they're visually messed up and can't be dismissed nor clicked.

Comment 5

[Richard Marti (:Paenglab)]

Attachment: image.png

Hmm, then something must be broken on my Win 11. I get native notifications. Clicking on the notification does not always go to the message.

Attached is my setting (unfortunately in German).

Comment 6

[Alessandro Castellani [:aleca]]

Oh I see, my settings for Daily were OFF, which is weird as I never modified that section in the Windows Settings.
I wonder if we need to register something in the background to properly hook into those settings and have them ON by default.

Comment 9

[Nick Alexander :nalexander [he/him]]

Hello :aleca -- my guess is that the 10 second delay you witness is here. What that means is that the notification server DLL integration is not working for Thunderbird; I can't say why that is without debugging help.

Toggle the Gecko preference alerts.useSystemBackend.windows.notificationserver.verbose=true, run with MOZ_LOG=WindowsAlertsService:5, and then check the Windows Event Viewer looking in Windows Logs > Application, IIRC.

:nrishel: anything else to suggest here?

Comment 10

[Nick Rishel [:nrishel]]

Looking back on Bug 1863798 it looks like the wrong impression was reached for how to fix the issue without investing the time to support the notification server (which tbh I don't think is that big a lift). The solution would have been to set alerts.useSystemBackend.windows.notificationserver.enabled to false - for reasons unclear to me they seem to have the impression it should be true.

Comment 11

[Alessandro Castellani [:aleca]]

(In reply to Nick Alexander :nalexander [he/him] from comment #9)

Hello :aleca -- my guess is that the 10 second delay you witness is here. What that means is that the notification server DLL integration is not working for Thunderbird; I can't say why that is without debugging help.

We ported the notification DLL in bug 1838139, maybe we missed something?

Toggle the Gecko preference alerts.useSystemBackend.windows.notificationserver.verbose=true, run with MOZ_LOG=WindowsAlertsService:5, and then check the Windows Event Viewer looking in Windows Logs > Application, IIRC.

Thanks for the pointers, I'll produce a debug log and ping you once I know more.

(In reply to Nick Rishel [:nrishel] from comment #10)

Looking back on Bug 1863798 it looks like the wrong impression was reached for how to fix the issue without investing the time to support the notification server (which tbh I don't think is that big a lift). The solution would have been to set alerts.useSystemBackend.windows.notificationserver.enabled to false - for reasons unclear to me they seem to have the impression it should be true.

In that bug you were interacting with a maintainer of a fork of Thunderbird. They usually tend to apply quick fixes and workarounds without fully investigating the causes and solving the root of the problem.

As a quick recap, this is what it happens with Thunderbird:
If we set both these prefs to FALSE

pref("alerts.useSystemBackend", false);
pref("alerts.useSystemBackend.windows.notificationserver.enabled", false);

• Clicking on a notification dismisses it correctly and selects the corresponding message.
• Thunderbird is not brought to the foreground (if in the background) nor restored from a minimized state.

If we set both these prefs to TRUE

pref("alerts.useSystemBackend", true);
pref("alerts.useSystemBackend.windows.notificationserver.enabled", true);

• Clicking on a notification doesn't dismisses it and it takes 10 seconds before the corresponding message is selected.
• Thunderbird is not brought to the foreground (if in the background) nor restored from a minimized state.

I pushed a patch to set both those prefs to FALSE so at least we don't stumble upon the 10 seconds delay problem, but I will need to continue investigating the reasons why the application is not brought to the foreground, which if I'm not wrong is what you tried to suggest with this sentence.

The least brittle approach IMO is to opt into the relaunch behavior and find some sensible action to take.

If so, could you elaborate a bit more on this?

Thank you both for your help

Comment 12

[Nick Rishel [:nrishel]]

:aleca I'm guessing Thunderbird has a different command line handler than BrowserContenthandler? You need to call to handeWindowsTag in whatever the equivalent command line handler is, this is where we handle it in Firefox for reference.

This is necessary because the notification server needs to transfer foreground permissions to the window to allow it to set itself as the foreground application. That's handled by passing the PID over a pipe back to the Notification Server, because the remote protocol somewhere along the way breaks the chain of sharing foreground permissions (or it's unable to receive the permissions due to not having a UI, not sure which). The 10 second delay you're seeing is the timeout on said pipe, at which point the notification server closes and allows calls to the Win8 style notification callbacks.

Comment 13

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/05dd7dd616ad
Set windows.notificationserver pref to false to temporarily fix 10 seconds delay for Windows notifications. r=john.bieling