Support notification actions
Categories
(Core :: DOM: Notifications, enhancement)
Tracking
()
People
(Reporter: marco, Unassigned)
References
(Depends on 1 open bug, Blocks 2 open bugs)
Details
(Keywords: dev-doc-needed, parity-chrome)
Updated•9 years ago
|
Updated•9 years ago
|
Comment 3•9 years ago
|
||
Comment 5•6 years ago
|
||
Now that all legacy add-ons are disabled maybe this should have a higher priority!
Hello! I'd love Firefox to implement actions. A recent project I worked on used Service Worker actions, and we had to tell users "to use Chrome instead", which is a pity.
I would like to jump on this bug, and help resolving it, but Firefox codebase is quite impressive.
Would it be possible to have some guidance?
I'm a JavaScript/node.js developer (10y+), with former Java background.
Comment 8•6 years ago
|
||
Hi Damien, which operating systems do you have access to? Each operating system has its own way of showing notifications and they each have different limitations related to actions. Our Windows implementation is also in the process of switching from non-native to native but that work has stalled a bit.
https://hg.mozilla.org/try/rev/259567171a79995b62f7d75273bb4594dc2ce73e will give pointers to where to change the DOM/IPC code… it doesn't touch the UI-frontends though.
It might make sense to implement this for one platform initially and then add the others in separate bugs. I think macOS or maybe Linux would be most straightforward as they won't need as much UX input since we're limited in what we can do there and can look at what other browsers do.
Comment 9•6 years ago
|
||
On that note, the (somewhat tricky to Google) spec for notifications on Linux is here:
https://developer.gnome.org/notification-spec/
Displaying a notification is accomplished by calling a D-Bus API and support for actions in the notification host is optional, so you need to call the GetCapabilities D-Bus API and check for actions
and action-icons
in the resulting list of capabilities.
Comment 10•6 years ago
|
||
Hi Stephan and Matthew.
I'm running dual boot with Linux Mint (Ubuntu based) and Windows 10. And I have an Android phone.
I'll try to start on the Linux implementation then.
Do you have any pointers on how this could tested automatically? there's so many test kind, I'm not sure which one is adapted.
Comment 11•6 years ago
|
||
(In reply to Damien from comment #10)
Hi Stephan and Matthew.
I'm running dual boot with Linux Mint (Ubuntu based) and Windows 10. And I have an Android phone.
OK, great!
I'll try to start on the Linux implementation then.
Sounds good.
Do you have any pointers on how this could tested automatically? there's so many test kind, I'm not sure which one is adapted.
We don't currently have a way to test the native notification UI so don't worry about that aspect. The web-developer facing aspect should be covered by Web Platform Tests while the internals of nsIAlert* can be tested via mochitests. Generally you can just look to see what existing tests are in the test/ directory.
Comment 12•6 years ago
|
||
Thanks! I'll make an attempt over the weekend.
Comment 13•6 years ago
|
||
Comment 14•6 years ago
|
||
(In reply to Damien from comment #10)
Do you have any pointers on how this could tested automatically? there's so many test kind, I'm not sure which one is adapted.
For this sort of thing, I tend to conceptually divide my tests into the following three layers:
-
Well-formedness tests (For each spec-incompliant thing a site may try to pass to the notifications API, how does Firefox refuse or sanitize it before it makes it to a D-Bus API call? Going the other direction, if what the notifications API allows isn't a strict superset of what the platform API allows, how does Firefox react to something that's allowed on the host platform but not in the web APIs?)
-
Graceful degradation tests (Stuff like "How does Firefox react to
GetCapabilities
reporting no actions support at all oractions
but notaction-icons
?) -
Integration tests (If you generate a notification from within an HTML page, does a mock notification daemon see the expected final result. If the mock generates a fake click on an action, does the test HTML see the expected result?)
Also, be aware that notification hosts in the wild can and do defy the spec in ways they think are harmless. (Primarily relating to what should and shouldn't accept HTML.)
For example, the spec only mentions that the body may contain HTML but it's been my experience that the notification title/summary will also be interpreted as HTML by at least some notification hosts.
For example, the version of KDE's notification host that I'm running applies the same sanitizer to the summary, body, and button labels, so you can generate some messed-up looking notifications by using tags like <br>
and <hr>
in the summary and action labels. (The summary will take as much space as it needs and extend across multiple lines. The action buttons will clip the rendered text to one line out of the center of the rendering, even if that means the button contains the bottom of one line and the top of another or just the <hr>
element.)
(In reply to Damien from comment #10)
We don't currently have a way to test the native notification UI so don't worry about that aspect.
That honestly surprises me, given how simple it is to spin up a test-specific D-Bus session bus (dbus-daemon --session --nofork --print-address
, then drop the resulting address into the DBUS_SESSION_BUS_ADDRESS
environment variable) and write a little mock notification host to listen on it.
...but maybe that's just down to my priorities when it comes to testing.
Comment 15•6 years ago
|
||
Thank you for all those instructions. They are very helpful.
But before jumping into it, I found a regression
When running freshly built firefox, and opening https://tests.peter.sh/notification-generator/, the site is requesting for permission, but the usual permission popup to grant them is nowhere to be found.
Using Firefox 66.0.2, I can grant permissions.
I could narrow the issue down to this (massive) commit: https://hg.mozilla.org/mozilla-central/rev/e8b3c73b4e32
Prior to it, permission popup will be shown. After it won't.
How do you usually handle such situations? Should I open a new bug?
Comment 16•6 years ago
|
||
Generally, yes open a new bug for regressions. However, I don't think this is a bug.
See https://blog.nightly.mozilla.org/2019/04/01/reducing-notification-permission-prompt-spam-in-firefox/
And specifically:
"we will temporarily deny requests for permission to use Notifications unless they follow a click or keystroke in Firefox Nightly from April 1st to April 29th."
So you'll need to click a button first rather than just expecting the prompt upon page load.
Comment 17•6 years ago
|
||
Thank you Chris.
I wasn't aware of it, and that feature will really make people's life easier.
Unfortunately, when on https://tests.peter.sh/notification-generator/, clicking or typing in the page does not triggers the notification permission prompt, making the site impossible to use.
Another example: https://serviceworke.rs/push-get-payload_demo.html.
Could this new behaviour require developers to completely change the way they invoke requestPermission() and showNotification()?
But maybe there's a better place to discuss this.
Comment 18•2 years ago
|
||
With PWAs becoming more popular in the recent times, I found out that actions are still only supported by Chromium-based browsers:
https://caniuse.com/mdn-api_notification_actions
With Safari adding support for WebPush next year, it stands to reason that Safari will implement this soon, too. What's the current status of notification actions in Firefox?
(In reply to nikeee from comment #18)
With PWAs becoming more popular in the recent times, I found out that actions are still only supported by Chromium-based browsers:
https://caniuse.com/mdn-api_notification_actionsWith Safari adding support for WebPush next year, it stands to reason that Safari will implement this soon, too. What's the current status of notification actions in Firefox?
It's a little complicated. For internal use, I sketched a bit more of the support for actions
in the code base. It wouldn't be particularly hard to push this across the line but it also isn't a priority (to the best of my knowledge).
Updated•2 years ago
|
Comment 20•2 years ago
|
||
The severity field for this bug is relatively low, S3. However, the bug has 3 duplicates and 12 votes.
:tspurway, could you consider increasing the bug severity?
For more information, please visit auto_nag documentation.
Reporter | ||
Updated•2 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Comment 21•2 years ago
|
||
Nick implemented the Alerts Service part in bug 1775136, thanks Nick! I guess we can track the DOM part here.
Updated•10 months ago
|
Description
•