Add an event for all notifications that are being shown




WebExtensions: Untriaged
a year ago
2 months ago


(Reporter: freaktechnik, Unassigned)


Firefox Tracking Flags

(Not tracked)


(Whiteboard: [design-decision-denied] triaged[notifications])



a year ago
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.


a year ago
Whiteboard: [design-decision-needed]


a year ago
Whiteboard: [design-decision-needed] → [design-decision-needed] triaged
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

a year ago
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.


5 months ago
Whiteboard: [design-decision-needed] triaged → [design-decision-needed] triaged[notifications]

Comment 3

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

Call in info:
Flags: needinfo?(amckay)

Comment 4

2 months ago
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>?
Flags: needinfo?(amckay)

Comment 5

2 months ago
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.
Last Resolved: 2 months ago
Resolution: --- → WONTFIX
Whiteboard: [design-decision-needed] triaged[notifications] → [design-decision-denied] triaged[notifications]
You need to log in before you can comment on or make changes to this bug.