1277809 - [meta] Simplify push notifications prompt

Status: RESOLVED INACTIVE

(Core :: DOM: Push Subscriptions, enhancement, P3)

Description

[Soledad Penades [:sole] [:spenades]]

Attachment: Door hanger prompt

The prompt (doorhanger?) for when a website tries to get the user to receive push notifications has too verbose answers and it's hard to process when you already have "door hanger fatigue" because apparently all websites now want you to get a notification before you even have a chance to look at the website

Current possible options for the prompt are

- Always receive notifications [looking slightly different from the other options in the drop down]
- Always block notifications
- Not now

Then when you open the "site info" bit (see screenshots), you get slightly different answers... which are simpler and easier to parse:

- Always ask
- Allow
- Block

I must have got the first prompt about 30+ times and dismissed it while feeling increasingly inconvenienced and thinking that a "block" option was not available... until I realised that the second option was "always block"

It would be easier to read and parse if the initial options were simplified and reordered to match the info box:

- Not now
- Allow
- Block

(Sorry if the bug has been filed under the wrong component but it's hard to say where it should go as Core: DOM Push notifications is the only one that pops up when you search for notifications - feel free to re-route to the right module)

Comment 1

[Soledad Penades [:sole] [:spenades]]

Attachment: Info pop up

Comment 2

[Lina Butler [:lina]]

Thanks for filing this! This has come up a lot in discussions about our permissions UX. :-) The doorhangers are being redesigned to fix the verbosity, and make it easier to deny the permission. Here's a link to the mock-ups: https://mozilla.invisionapp.com/share/PC3Y0QSRK#/screens/96290115

It sounds like that work will be landing in stages, but notifications and Push should be one of the first to get the new design.

Comment 3

[Lina Butler [:lina]]

Adding the (eventual) implementation bug as a "see also" instead of a dupe, because I think this bug is easier to find, and summarizes where the current design falls short.

Comment 4

[Andrew Overholt [:overholt]]

Bug 1267609 got duped to bug 1282768.

Should we keep this around as a description of the general problems or CC Soledad on each of the specific fixes? :P

Comment 5

[Lina Butler [:lina]]

Sole, which would you prefer? I don't think we have a bug on file about the pitfalls of the current doorhanger, and why we need to make it better. Maybe bug 1188147? If that doesn't really fit, let's keep this one around.

Comment 6

[Soledad Penades [:sole] [:spenades]]

I looked at the other bug titles and they're certainly not very evocative/clear of what they're aiming to achieve for me as an end user. Should they be made to block this one? I think I would see the updates in that case.

Comment 7

[Cork]

Could we at the same time get a separation between push notifications and webnotifications?

Telegram is using the new pushnotification api and i see more and more users confused by this in the irc channel.

Comment 8

[Lina Butler [:lina]]

It's too late for that, unfortunately. We merged the push and web notifications permissions for a few reasons:

* Explaining the difference in the doorhanger, without resorting to technical jargon, is hard. They're both notifications, but one can be sent in the background. I think we did some preliminary research on this, and most people didn't understand what that meant.
* Showing a notification in response to a push message still requires the web notifications permission. This meant people would see two doorhangers, sometimes one after the other, which also made for a poor experience.
* Pushes can silently update the app without showing a notification at all (Firefox restricts this when the page isn't open, and will eventually drop the site's subscription to mitigate bad behavior. But it's still useful to have on occasion).
* We noticed sites assumed `Notification.requestPermission` and `pushManager.subscribe()` were controlled by the same permission, and wrote code like `Notification.requestPermission().then(perm => { /* ... Some time later ... */ return serviceWorkerRegistration.pushManager.subscribe(); })`.

Chrome consolidated the permissions when they shipped push as well. We considered the UX, and agreed we should do the same.

Comment 9

[Hugo Osvaldo Barrera]

I agree that two doorhangers are a bad idea, but why not just a checkbox "Also allow background notifications" and make the distinction? You can always include this checkbox (regardless of what the site specifically prompted), but only grant according to the user's selection.

The *huge* problem with "always-or-never" authorization, is that we have to chose between allowing a website to permanently nag us, or have it half-broken. For example, I occasionally use web.telegram.org. I want notifications while I'm using it, but I don't want hundreds of notifications all over the place for a website that I'm clearly not using (I close it for a reason).

Sure, I can use incognito, or delete cookies when I leave, or revoke and grant permissions every time I open any site I want notifications for, but that's obviously a way worse UX workaround than anything else.

Comment 10

[Andrew Overholt [:overholt]]

(Should have marked this meta bug as P3 a while ago)

Comment 11

[Kagami Rosylight [:saschanaz] (they/them) (OOO until Dec 11)]

I think Notification.requestPermission now requires transient user activation. Anyway this is inactive.