1280875 - Add an event for all notifications that are being shown

Status: RESOLVED WONTFIX

(WebExtensions :: Untriaged, enhancement)

Description

[Martin Giger [:freaktechnik]]

I propose an event in extensions that is fired, whenever a notification is shown. It should have rough category filters for its origin like "website", "webextension" and "native" or similar. The listener to the event would then receive a basic description of the notification, including title, icon, description and category.
This would already cover extensions that build on notifications to do things like notification mirroring or other actions upon notifications, like playing a specific sound etc.

If there then was the ability to listen to the event "blocking" and cancel a notification this would add notification filtering or notification deamon replacement (like gNotifier) to the possibilities of WebExtensions.

The reason I explicitly listed "webextension" as a distinct category and not "extensions", is because built-in notifications and notifications from XPCOM extensions look the same to the alerts service.
It might also be useful to pass on the origin URL of a notification.

So far this was (to my knowledge) only possible by replacing the nsIAlertService, which always was a sub-optimal solution. However I do think such an API would be easy to implement and shouldn't be too powerful.

Comment 1

[Andy McKay]

There is some concern that this would allow WebExtensions to escape outside their sandbox and possibly have privacy or security concerns. Especially since there are lots of notifications across Firefox that we or may not know about.

Would it make sense to limit this to say just "websites" and have a similar set of URLs that we do for content scripts to limit the notifications to just some websites or all websites?

Comment 2

[Martin Giger [:freaktechnik]]

If you limit it just to websites there is no need for an API - you can just use a content-script and try wrapping the API there.

The point of this API is to a degree to give deeper access to the notification daemon, if the content of certain notifications is potentially a security concern the content could just be omitted and just the source "native" or similar be given.

I am aware that canceling notifications is a bit of a stretch and very prone to "breaking Firefox", and I do not think it is necessary, but it would (as I wrote) massively expand the use-cases. Limiting what this method to just notifications to websites would probably be still interesting.

Comment 3

[Andy McKay]

This has been added to the agenda for the May 30 WebExtensions Triage meeting at 10:30am PT.

Call in info: https://wiki.mozilla.org/Add-ons/Contribute/Triage#Details_.26_How_to_Join
Agenda: https://docs.google.com/document/d/1hKKRpGFIaAaI3G_HfPX2Nk8pCchyhUIKJB9y5sIrVV4/edit

Comment 4

[Andy McKay]

Some comments from the meeting:

* We try to avoid anything blocking, is the "blocking" part a requirement for your use case? That would be needed for cancelling a notification.
* The ability to be able to see the notifications means that you can see activity from other extensions, that's a concern for privacy.
* For websites should this be requiring a host pattern to allow access, so you'd have to ask for access to notifications for <all_urls>?

Comment 5

[Andy McKay]

I spoke to Martin in IRC and this point he doesn't have a particular use case for this either. Given concerns about what this would be used for and a lack of use-cases, let's just say no for the moment.

Comment 6

[Martin Giger [:freaktechnik]]

I have since created a WebExtension version of what I would use this API with. As it turns out, you can catch most notifications that matter to users, except for notifications sent from service workers. Though I am not sure if exposing an API for notifications is the best way to approach the problem of catching service worker notifications, or if there is a more generic approach that would also help other extensions trying to deal with service workers.

Comment 7

[Andy McKay]

Glad to here you got it mostly working. We certainly should try to do more to integrate with service workers at some point, but that's probably a seperate bug :)