1497425 - Turn on Toast Notification on release channel

Status: RESOLVED FIXED

(Toolkit Graveyard :: Notifications and Alerts, enhancement, P2)

Description

[Makoto Kato [:m_kato]]

bug 1155505 is implemented for nightly, but this isn't turn on release channel yet.

Comment 1

[Ryan VanderMeulen [:RyanVM]]

(In reply to Sylvestre Ledru [:sylvestre] from bug 1155505 comment #73)
> Release Note Request (optional, but appreciated)
> [Why is this notable]: User facing change
> [Affects Firefox for Android]: No
> [Suggested wording]: On Windows, notifications will be sent using the native
> system (Toast).
> (better wording is welcome)

Once this bug is fixed, we probably want to relnote it for whatever train it's riding.

Comment 2

[Pascal Chevrel:pascalc (PTO until April 26)]

Makoto, are there plans to activate this feature in 67? Thanks

Comment 3

[Ryan VanderMeulen [:RyanVM]]

Removing the relnote request to get this off the radar for now. If/when we get closer to making this happen, feel free to re-nominate.

Comment 4

[Makoto Kato [:m_kato]]

Thanks, Julien. I am not working on desktop version as primary work. So no plan to turn on this for release build. If Desktop UX wants to enable this feature, I can help this.

Comment 6

[Kagami Rosylight [:saschanaz] (they/them)]

Continuing from the previous internal conversation:

We do have a telemetry for pushManager.subscribe() (which is called for initial subscriptions for push notifications) but not for new Notification() (which should be called for each notification). I intend to add one, but I need to make sure doing so will help convince the team.

Gijs, would the suggested telemetry will help decision about this for you and :rtestard, either positive or negative? Thanks!

Comment 7

[:Gijs (he/him)]

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

Continuing from the previous internal conversation:

We do have a telemetry for pushManager.subscribe() (which is called for initial subscriptions for push notifications) but not for new Notification() (which should be called for each notification). I intend to add one, but I need to make sure doing so will help convince the team.

As far as I can tell you can create the notification just fine even if your site doesn't have permission (but then it won't be displayed)? So even a use counter for that wouldn't really map to actual notifications being displayed?

Also, AIUI, the current implementation "works" in the sense that notifications are displayed, so the impact isn't about getting notifications or not getting them at all. The issues are around Windows 10 API integration, so notifications look native, can be snoozed, and so they can be tracked in the notification center, and around a11y. Is that fair? If so, assessing the size of the impacted population would have to center around how many people rely on those bits of Windows functionality in combination with websites that use the relevant APIs in Firefox.

We probably can't get some of that information, but I suppose total use of notifications would provide us with some upper bound. We could also check how often such notifications appear while the user is idle (which you can check with nsIIdleService), or whether users getting these are using assistive technology.

Gijs, would the suggested telemetry will help decision about this for you and :rtestard, either positive or negative? Thanks!

I can't comment on whether Romain or other PMs would think the telemetry you propose would be sufficient to make such a call. You'd be best off talking to them directly.

I think we can definitely keep this in the backlog of work, but I'm pretty skeptical that the numbers on this feature's use will soon justify spending a lot of time on it over other work we could be doing. "do not disturb", keeping your machine on for long periods without putting it to sleep, etc. are all fairly technical/advanced-user things, and so the delta with the status quo is pretty limited for most users. I actually suspect the accessibility aspect is the best reason to resource this - but then, none of us have seen numbers so who knows, I could be totally wrong. :-)

Comment 8

[Kagami Rosylight [:saschanaz] (they/them)]

(In reply to :Gijs (he/him) from comment #7)

As far as I can tell you can create the notification just fine even if your site doesn't have permission (but then it won't be displayed)? So even a use counter for that wouldn't really map to actual notifications being displayed?

We probably can't get some of that information, but I suppose total use of notifications would provide us with some upper bound. We could also check how often such notifications appear while the user is idle (which you can check with nsIIdleService), or whether users getting these are using assistive technology.

Hmm, I guess a custom use counter may be able to provide that information. (Not sure how to check a11y thing though)

I can't comment on whether Romain or other PMs would think the telemetry you propose would be sufficient to make such a call. You'd be best off talking to them directly.

I'll do, thanks! (Adding NI...) Hi Romain, could you share your opinion about what would help your decision to get some push here? Would the data suggested from Gijs in comment #7 (counting notifications when in idle / with assistive tech) help?

I think we can definitely keep this in the backlog of work, but I'm pretty skeptical that the numbers on this feature's use will soon justify spending a lot of time on it over other work we could be doing. "do not disturb", keeping your machine on for long periods without putting it to sleep, etc. are all fairly technical/advanced-user things, and so the delta with the status quo is pretty limited for most users. I actually suspect the accessibility aspect is the best reason to resource this - but then, none of us have seen numbers so who knows, I could be totally wrong. :-)

Yeah, I rather prefer to get a negative decision rather than just "no data, can't decide". 😁

Comment 9

[Kagami Rosylight [:saschanaz] (they/them)]

comment #8 somehow didn't set NI correctly.

Comment 10

[Kagami Rosylight [:saschanaz] (they/them)]

Attachment: focus assist

Another point. Focus Assist on Windows is not something only for advanced users, it can also be automatically enabled in very basic situations:

• It's night
• A game is being played
• An app is in fullscreen state

Furthermore, notifications can be lost in the last two situations even when a user is actively using their device.

I'd also like to include Chrome telemetry in our decision process (where notification creation happens in over 2% of page loads), as I can certainly imagine users not subscribing push notifications because they think it's not very helpful on Firefox.

Comment 11

[Romain Testard [:RT]]

Does PUSH_API_NOTIFY (https://probes.telemetry.mozilla.org/?search=ush+api+notify&view=detail&probeId=histogram%2FPUSH_API_NOTIFY) represent volumes of displays of web notifications? If so we should be able to understand trends and monthly users affected .
The value of the Windows action center integration likely depends of the level of usage of Windows action center itself (there can be many notifications but no retrieval from the AC). I'm unsure that telemetry would help bring a justification based on accessibility volumes given how low volumes of screen reader users are (https://sql.telemetry.mozilla.org/queries/75983/source#189504 if accessibility software is the best proxy for accessibility needs here) but if the Windows action center gets used in significant volumes then it's likely a good enough argument (notifications are now displayed on the locked screen which may also add value to users).
I'mm NIing Aaron for opinion regarding value for supporting the action center in Windows 10.

Comment 12

[Matthew N. [:MattN]]

(In reply to Romain Testard [:RT] from comment #11)

Does PUSH_API_NOTIFY (https://probes.telemetry.mozilla.org/?search=ush+api+notify&view=detail&probeId=histogram%2FPUSH_API_NOTIFY) represent volumes of displays of web notifications?

Not really. Many notifications aren't caused by Push but instead by open tabs. WEB_NOTIFICATION_SHOWN is probably closer to what you want.

Comment 13

[Kagami Rosylight [:saschanaz] (they/them)]

(In reply to Matthew N. [:MattN] from comment #12)

(In reply to Romain Testard [:RT] from comment #11)

Does PUSH_API_NOTIFY (https://probes.telemetry.mozilla.org/?search=ush+api+notify&view=detail&probeId=histogram%2FPUSH_API_NOTIFY) represent volumes of displays of web notifications?

Not really. Many notifications aren't caused by Push but instead by open tabs. WEB_NOTIFICATION_SHOWN is probably closer to what you want.

WEB_NOTIFICATION_SHOWN has no data on the dashboard and doesn't exist in mozilla-central per searchfox, do you know what happened there?

Comment 14

[:Gijs (he/him)]

(In reply to Kagami :saschanaz [off 28 June - 16 July] from comment #13)

(In reply to Matthew N. [:MattN] from comment #12)

(In reply to Romain Testard [:RT] from comment #11)

Does PUSH_API_NOTIFY (https://probes.telemetry.mozilla.org/?search=ush+api+notify&view=detail&probeId=histogram%2FPUSH_API_NOTIFY) represent volumes of displays of web notifications?

Not really. Many notifications aren't caused by Push but instead by open tabs. WEB_NOTIFICATION_SHOWN is probably closer to what you want.

WEB_NOTIFICATION_SHOWN has no data on the dashboard and doesn't exist in mozilla-central per searchfox, do you know what happened there?

It was removed in bug 1429016, 2 years ago (FWIW, I found this through code archaeology. You can use the old ESR versions on searchfox to find a revision where the telemetry exists (e.g. esr60), then go to hg web, then use "revisions" to find a revision identifier for the same file that exists in mozilla-central, open the file with that revision instead of tip, and in mozilla-central instead of the esr60 repo, then when you hover over lines on e.g. https://hg.mozilla.org/mozilla-central/file/7818e2f5572c3e90c14d0d42881d793864baa2e4/dom/notification/Notification.cpp#l1396 , click "+" on the line before the line you're interested in, "-" on the line after, then ask for "newer" revisions, which opens this link. bug 1514812 got filed to reintroduce telemetry.

Comment 15

[Nick Rishel [:nrishel]]

No longer blocking due to changes in 1774082.

Comment 16

[Nick Rishel [:nrishel]]

Attachment: Bug 1497425 - Enable native notifications by default on Windows. r=nalexander

Depends on D166442

Comment 17

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/7ec889d035f3
Enable native notifications by default on Windows. r=nalexander

Comment 18

[Sandor Molnar[:smolnar]]

https://hg.mozilla.org/mozilla-central/rev/7ec889d035f3

Comment 19

[Donal Meehan [:dmeehan]]

:nrishel could you please consider nominating this for a relnote?
https://wiki.mozilla.org/Release_Management/Release_Notes#Nomination_in_Bugzilla

Comment 20

[Nick Rishel [:nrishel]]

[Why is this notable]:
Native notification support for Windows was a highly requested feature.

[Suggested wording]:
Windows native notifications are now enabled by default.

[Links (documentation, blog post, etc)]:
No link but this is a strong candidate for an accompanying fun screenshot.

Comment 21

[Donal Meehan [:dmeehan]]

Thanks, added to Nightly release notes.
Keeping the relnote? flag open to keep it on the radar for inclusion in our final release notes.

Comment 22

[John Bieling (:TbSync)]

For Thunderbird, the callback registered via mNotification->add_Activated here never seems to fire and we therefore do not get the notification for alertclickcallback here.

We noticed this when the notifications WebExtension API no longer issued the onClicked event for Thunderbird, see https://bugzilla.mozilla.org/show_bug.cgi?id=1828097#c9

Do you have any pointers for me to understand why this callback never fires for Thunderbird? I was not able to trace it any deeper, as I could not find the actual implementation of add_Activated in IToastNotification or where the actual click is captured.

Comment 23

[Kagami Rosylight [:saschanaz] (they/them)]

as I could not find the actual implementation of add_Activated in IToastNotification or where the actual click is captured.

This is a Windows API: https://learn.microsoft.com/en-us/uwp/api/windows.ui.notifications.toastnotification.activated?view=winrt-22621

Comment 24

[John Bieling (:TbSync)]

Oh, thanks for that puzzle piece.

What could Thunderbird do differently compared to Firefox, so that the same toolkit/widget code does not cause that Windows API to actually issue the Activated event? Is there some additional step to globally enable the event, which Thunderbird does not yet do?

Comment 25

[Nick Alexander :nalexander [he/him]]

(In reply to John Bieling (:TbSync) from comment #24)

Oh, thanks for that puzzle piece.

What could Thunderbird do differently compared to Firefox, so that the same toolkit/widget code does not cause that Windows API to actually issue the Activated event? Is there some additional step to globally enable the event, which Thunderbird does not yet do?

Firefox does significant work to dynamically register a new notificationserver.dll and route Windows 10+ notifications through it. This enables launching the app to handle notifications remaining in the Action Centre. Something here is not working for TB: it might be as simple as the notification server not being built or not being packaged in TB, I don't know. (This will depend on what Firefox revision TB is based on.)

John: please file a ticket to track TB bustage of notifications -- this isn't the place to continue this discussion. Thanks!

Comment 26

[Nick Rishel [:nrishel]]

Clearing NI as it seems that this will be discussed elsewhere. Feel free to ping me in the next issue.