Turn on Toast Notification on release channel
Categories
(Toolkit Graveyard :: Notifications and Alerts, enhancement, P2)
Tracking
(relnote-firefox 111+, firefox111 fixed)
People
(Reporter: m_kato, Assigned: nrishel, NeedInfo)
References
(Depends on 1 open bug)
Details
Attachments
(2 files)
Reporter | ||
Updated•6 years ago
|
Updated•6 years ago
|
Comment 1•6 years ago
|
||
Comment 2•6 years ago
|
||
Makoto, are there plans to activate this feature in 67? Thanks
Comment 3•5 years ago
|
||
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.
Reporter | ||
Comment 4•5 years ago
|
||
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.
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•4 years ago
|
||
(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 fornew 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. :-)
(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". 😁
Updated•4 years ago
|
comment #8 somehow didn't set NI correctly.
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•4 years ago
|
||
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•4 years ago
|
||
(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.
(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•3 years ago
|
||
(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.
Assignee | ||
Comment 15•2 years ago
|
||
No longer blocking due to changes in 1774082.
Updated•2 years ago
|
Assignee | ||
Comment 16•2 years ago
|
||
Depends on D166442
Updated•2 years ago
|
Comment 17•2 years ago
|
||
Comment 18•2 years ago
|
||
bugherder |
Comment 19•2 years ago
|
||
:nrishel could you please consider nominating this for a relnote?
https://wiki.mozilla.org/Release_Management/Release_Notes#Nomination_in_Bugzilla
Assignee | ||
Comment 20•2 years ago
|
||
[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.
Updated•2 years ago
|
Comment 21•2 years ago
|
||
Thanks, added to Nightly release notes.
Keeping the relnote? flag open to keep it on the radar for inclusion in our final release notes.
Updated•2 years ago
|
Comment 22•1 years ago
|
||
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.
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•1 years ago
|
||
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•1 years ago
|
||
(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!
Assignee | ||
Comment 26•1 years ago
|
||
Clearing NI as it seems that this will be discussed elsewhere. Feel free to ping me in the next issue.
Updated•1 years ago
|
Updated•1 years ago
|
Updated•1 year ago
|
Description
•