Open Bug 1225110 Opened 4 years ago Updated Last month

Support notification actions

Categories

(Toolkit :: Notifications and Alerts, defect)

defect
Not set

Tracking

()

Tracking Status
firefox42 --- affected
firefox43 --- affected
firefox44 --- affected
firefox45 --- affected

People

(Reporter: marco, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: dev-doc-needed)

Blocks: WADI
Component: DOM: Push Notifications → Notifications and Alerts
Product: Core → Toolkit
Depends on: 1236777
No longer depends on: 1236777
Duplicate of this bug: 1283796
Duplicate of this bug: 1286536
I think Chrome currently supports actions; might be nice to have an entry on https://developer.mozilla.org/en-US/docs/Web/API/Notification.
Keywords: dev-doc-needed
Duplicate of this bug: 1464158

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.

Maybe MattN can help.

Flags: needinfo?(MattN+bmo)

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.

Flags: needinfo?(MattN+bmo)

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.

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.

(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.

Thanks! I'll make an attempt over the weekend.

Also, if you haven't found them already:

  • The backend for libnotify on Linux lives here and here.
  • macOS is here.
  • Windows is here and here
  • Our fallback XUL backend is here.

(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:

  1. 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?)

  2. Graceful degradation tests (Stuff like "How does Firefox react to GetCapabilities reporting no actions support at all or actions but not action-icons?)

  3. 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.

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?

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.

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.

You need to log in before you can comment on or make changes to this bug.