(In reply to Makoto Kato [:m_kato] from comment #1)

To implement this, INotificationActivationCallback is required and it
implements on a process that is COM server.

This article suggests you can persist notifications with No COM / Stub CLSID (no COM activator):

For classic Win32 apps, set up the AUMID so that you can send toasts, and then also specify a CLSID on your shortcut. This can be any random GUID. Don't add the COM server/activator. You're adding a "stub" COM CLSID, which will cause Action Center to persist the notification. Note that you can only use protocol activation toasts, as the stub CLSID will break activation of any other toast activations. Therefore, you have to update your app to support protocol activation, and have the toasts protocol activate your own app.

Maybe there's some reason Firefox can't use this, though; I don't know how our implementation works.

For classic Win32 apps, set up the AUMID so that you can send toasts, and then also specify a CLSID on your shortcut. This can be any random GUID. Don't add the COM server/activator. You're adding a "stub" COM CLSID, which will cause Action Center to persist the notification. Note that you can only use protocol activation toasts, as the stub CLSID will break activation of any other toast activations. Therefore, you have to update your app to support protocol activation, and have the toasts protocol activate your own app.

Maybe there's some reason Firefox can't use this, though; I don't know how our implementation works.

Actually, we already use CLSID (AppUserModeID/AUMID) in Firefox shortcut. I guess that protocol activator has to register the specific protocol in window registry. If Firefox is default browser, we may be able to use http:// in toast XML (<actions><action activationType="protocol" argument="http:abc">... etc for toast notification. But I don't investigate this yet.

This has been working for at least a year with alert.useSystemBackend=true, but not with =false. I guess this does not block but is blocked by bug 1497425.

Try with: https://www.webpushnotifications.com/html5-browser-push-notifications-example-demo

For me, with alert.useSystemBackend=true, notifications still don't remain in Windows 10 Action Center. I'm on the latest nightly on Windows 10 20H2 19042.541. Whether I let the notification time out/dismiss on its own, or click the x on the notification, it doesn't remain in my Action Center

What does your notification look like? Could you share a screenshot?

I reported this issue two years ago in 1545326 https://bugzilla.mozilla.org/show_bug.cgi?id=1545326

(In reply to Kagami :saschanaz from comment #6)

What does your notification look like? Could you share a screenshot?

This is what my notifications look like with alert.useSystemBackend=true. Whether I let the notification time out/dismiss on its own, or click the x on the notification, it doesn't remain in my Action Center

@emanuel per 1545326 from April 2020

"But, alerts.useSystemBackend = true isn't ready to ship yet, because it has bugs, like the one you saw in comment 7, as well as other bugs blocking the meta bug 1497425. Unfortunately, this feature hasn't been prioritized, and there's no one actively working on notifications now. Because of that, I'm sorry to say that we aren't likely to turn on Windows native notifications with action center integration anytime soon. ☹️"

That comment made me switch to a Chromium based browser sorry to say.

Ran into this same issue recently. I would like to implement push notifications in both Edge and Firefox, but this is problematic. The notification toast pops up but disappears and does not remain in the action center making the push notifications through Firefox worthless. Hope this gets fixed!

If we can't use protocol activation for some reason:

(In reply to Makoto Kato [:m_kato] from comment #1)

I think that firefox shouldn't be COM server,

Why? Our parent process already has a message loop and we're already running, so in some ways, this is the easiest approach. Unless we have to make sync calls to respond to this callback?

so we should add new exe
process (toastactivator.exe?) that has INotificationActivationCallback's COM
server.

Note that we may not need to create our own exe. We may instead be able to write a (potentially simpler) dll COM server and set it up to use the system-provided dll surrogate.

[Tracking Requested - why for this release]: This has been broken for too long and has me gravitating towards Chromium. It'd be nice for this to go out along the Proton redesign.

Sorry to say but that is what I have done. After reporting https://bugzilla.mozilla.org/show_bug.cgi?id=1545326 and nothing happening on fixing that issue. I have been using a Chromium-based browser for a year now after using Firefox forever.

I also try to receive notifications in the notification center. I receive the notification, but it does not stay in the notification center. I have to keep a chrome for that. Is the problem solved with the latest nightly version?

This issue also affects new email notifications in Thunderbird 91. It has become virtually useless now when new email notification is gone almost immediately, so you have to switch to the Thunderbird to check if there are any new emails when you were off the computer for more than few seconds.

I dug into this a bit and I think the root cause is that we tear down the notification when we the dismissed callback occurs, but we can get multiple dismissals (first a timeout of the toast, later after being dismissed from the action center). If we don't teardown when the toast times out the notification does not disappear from the notification center.

What I'm describing above is different from this bug report though the root cause is similar: notifications dismissed as a toast also tear down the action center notification. Reasonable people could disagree on what the correct behavior is here, so we'll probably want to choose a direction and expose a config to change it.

Windows already provides a way to separately control the toast and action center notifications. It seems like Firefox does not need a new config option, but should instead properly handle the settings that already exist in Windows.

I think our impl can follow what Edge does: It does not follow dismissal (and thus no close event).

But then nothing can remove the handlers in the current impl, which will let ToastNotification::mActiveHandlers grow indefinitely 🤔. What's your plan about this?

@Kagami It seems that the correct way to handle mActiveHandlers growth this is to check the notification history for an active toast in the case of dismissal (we could count the dismissals but as shown above we may not receive more than one). That said I'm not yet certain how changes necessary for notifications that persist and are interactive after Firefox is closed will impact how we track handlers.

Also it seems that there's a platform encouraged way to add dismiss toast and action center notifications, therefore the toast's x button should be treated as hide instead of dismiss all.

Resolved by https://phabricator.services.mozilla.com/D151741.

Note: After Firefox is closed the notification isn't actionable (clicking it doesn't do anything). Follow up bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1783081

Is the fix going to be promoted to Thunderbird as well? There is simiar issue with the lost Windows native notifications.

(In reply to Petr Vones from comment #23)

Is the fix going to be promoted to Thunderbird as well? There is simiar issue with the lost Windows native notifications.

That's a question for the Thunderbird developers - I suggest opening a bug in https://bugzilla.mozilla.org/enter_bug.cgi?product=Thunderbird&component=General for this.

(In reply to Petr Vones from comment #23)

Is the fix going to be promoted to Thunderbird as well? There is simiar issue with the lost Windows native notifications.

See bug 1701728.

(In reply to Petr Vones from comment #23)

Is the fix going to be promoted to Thunderbird as well? There is simiar issue with the lost Windows native notifications.

I'll add that Firefox team is working to make Windows native toast notifications the "default backend" for Windows users; the work in this area to make notifications persistent, update styling, partially support actions, etc, is part of this. There will be some Thunderbird-specific work required to take advantage of these changes (e.g., the equivalent of https://bugzilla.mozilla.org/show_bug.cgi?id=1774082) but the basic approach should be possible. The hard part is what to do with a notification that re-launches the application; in general, the state to process the notification is gone. Firefox doesn't handle this in any meaningful generality -- we launch Firefox and navigate to a URL -- and Thunderbird will have to do some integration work to think through what is actually desired and appropriate here.