Open Bug 1346375 Opened 8 years ago Updated 1 year ago

Support requireInteraction (requires Toolkit::Notifications and Alerts and platform support)

Categories

(Core :: DOM: Notifications, enhancement, P3)

52 Branch
enhancement

Tracking

()

Tracking Status
firefox55 --- wontfix
firefox56 --- wontfix
firefox57 - wontfix

People

(Reporter: clarkbw, Unassigned)

References

(Blocks 3 open bugs)

Details

(Keywords: compat, parity-chrome, parity-edge)

Filing this from bug 862395 Hello. requireInteraction does not seem to be working on the 52 release 52.0 (32-bit, Windows 10). Same code works on Chrome. //From the app Notification.requestPermission(function (status) { if (status != "granted") return; navigator.serviceWorker.ready.then(function (registration) { if (!registration.showNotification || !registration.getNotifications) return; registration.showNotification('test', { body: 'test', icon: '../img/icon192.png', tag: "myId", silent: true, requireInteraction: true, data: { action: "test" } }); }); //From the service worker, I have: self.addEventListener('notificationclick', function (event) { The notification shows but it still auto-closes. The service worker receives the clicks, however I have verified that event.notification.requireInteraction is not set in the event.notification object from the click above. In Chrome, it is set to true.
It appears we explicitly disable requireInteraction on everything except nightly. https://dxr.mozilla.org/mozilla-central/source/modules/libpref/init/all.js#4801 Can you try setting "dom.webnotifications.requireinteraction.enabled" to true in about:config?
Flags: needinfo?(zmandel)
William, do you know why we disable requireInteraction like this?
Flags: needinfo?(wchen)
(In reply to Ben Kelly [not reviewing due to deadline][:bkelly] from comment #2) > William, do you know why we disable requireInteraction like this? I think we initially decided to disable because we previously has a poor user experience with the push permission prompt. It would be worth revisiting this now that the permission prompts have been re-implemented.
I think the other issue was that we didn't have good UX for XUL notifications because we don't have a good way to stack them right now and this becomes a bigger issue when notifications aren't dismissed automatically.
Flags: needinfo?(wchen)
Bummer because some apps (like mine) were explicitly checking for notification support in web workers to enable the app notification functionality, as it assumed it would be 100% compliant. However, not supporting requireInteraction breaks the functionality of my entire feature in this case.
Flags: needinfo?(zmandel)
Bryan, I guess we should talk about UX here.
Flags: needinfo?(clarkbw)
Priority: -- → P3
Peter, you probably don't have time for this but perhaps you can point me to the right UX person for notifications and I can try to keep up with this on spare cycles.
Flags: needinfo?(clarkbw) → needinfo?(pdolanjski)
Bryan, if you can take Jacqueline through it, she may be able to help.
Flags: needinfo?(pdolanjski) → needinfo?(jsavory)
Hey Bryan, I'm happy to help out here, however I am still fairly new to the desktop UX designs so if you could let me know exactly what the UX concern is I'll do what I can. :)
Flags: needinfo?(jsavory) → needinfo?(clarkbw)
Jacqueline, I just sent over an invite for tomorrow so we can walk through this. I'll drop some notes into this bug afterward. Thanks!
Flags: needinfo?(clarkbw)
Ok, we're going to look at a near term and some longer term solutions to get this enabled in Fx release. A near term solution might be limiting the number of requireInteraction notifications per domain to prevent too many notifications sitting around. The longer term solution would be something like a notification stacking system that allows for no limits per domain but collapses the number of required notifications so there isn't a long list of required notifications stacking up the side of your screen. Jacqueline is going to connect with phlsa about previous designs done in this space for near and longer term solutions.
As Bryan mentioned, for the short term I think it would be best to limit the requireInteraction per domain since we only show one notification at a time. I'm thinking that we should allow only 3 requireInteraction notifications per domain, however let me know if this sounds like too many. In terms of the longer term solution, the stacking possibilities look great but will require a little more time and review before its ready to go.
> Can you try setting "dom.webnotifications.requireinteraction.enabled" to true in about:config? I can confirm that setting it to true does not make notifications require interactions anyway (works on Chrome). Is there something else that needs to be done?
Yes, I tried setting the about:config key, and even restarted, but it doesnt work.
¡Hola Jacqueline! Ended up trying to help a user on https://support.mozilla.org/questions/1174458 Is there a preference to flip to make this work on Firefox 56.0b8 and 55.0.3? ¡Gracias! Alex
Flags: needinfo?(jsavory)
[Tracking Requested - why for this release]: It might be neat to have for Quantum...
Hi Alex! Unfortunately I'm not very familiar with the pref flips for this bug, but hopefully one of the developers can help you? Would anyone know the answer to Alex's question?
Flags: needinfo?(jsavory)
Any update on enabling this? The pref flip works for me on Windows.

The preference "dom.webnotifications.requireinteraction.enabled" is still not working in Firefox 75. When that is set to 'true', notifications still disappear after a few seconds without being dismissed.

requireInteraction works fine when dom.webnotifications.requireinteraction.enabled is true on Firefox 89 at least on Windows.

I reported this on github too:
https://github.com/mdn/browser-compat-data/issues/11353

This is still broken in Firefox 98.0.1, running on macOS 12.3: requireInteraction: true has no effect on the notification, which disappears after a few seconds. The behaviour is the same with dom.webnotifications.requireinteraction.enabled set to either true or false.

Here's a simple test case: https://cdpn.io/pen/debug/yLpaxJa?authentication_hash=vPrKKNpoYzmr

The test case above works in Chrome on the same platform.

The dom.webnotifications.requireinteraction.enabled has been enabled on nightly for years. It looks it worth re-triaging this issue and sort out a plan for this. Or maybe at least look into the option of disabling on nightly for now?

Flags: needinfo?(jstutte)

Forwarding to :asuth for thoughts.

Flags: needinfo?(jstutte) → needinfo?(bugmail)

I’m using Firefox on Windows with system notifications. I finally found out about the dom.webnotifications.requireinteraction.enabled switch a few minutes ago. It was disabled for me, so I turned it on. That doesn’t seem to make requireInteraction work.

Is it supposed to work? Right now my only option is to spam myself with notifications if I want to make sure they’re up and clickable.

Is there no traction on this? Is there anything else I can do other than provide easy to reproduce test case as above?

This is proving to be quite a problematic bug, in that notifications that should always, well, require interaction, instead are missed completely, rendering a great number of services rather useless, unfortunately.

Severity: normal → S3

Bug 1794475 explicitly addresses this case in the context of Windows and https://bugzilla.mozilla.org/show_bug.cgi?id=1794475#c0 is a good reflection of the same problems that we faced here in comment 4. (Namely that our desktop alert UI did not have an interaction model that supported notifications that stuck around, although Firefox OS did.) https://bugzilla.mozilla.org/show_bug.cgi?id=1545326#c18 also provides relevant context.

Because this issue spans multiple components (this one, Toolkit::Notifications and Alerts, plus the widget bindings for each supported platform), this bug should likely be left open even if most of the work will happen in related bugs.

Blocks: 1497427
Type: defect → enhancement
Depends on: 1794475
Flags: needinfo?(bugmail)
Summary: requireInteraction doesn't seem to be working → Support requireInteraction (requires Toolkit::Notifications and Alerts and platform support)
No longer duplicate of this bug: 1417846
You need to log in before you can comment on or make changes to this bug.