:Harald Kirschner :digitarald Reporter
	Description • 9 years ago

The use case is a push service provider that redirects the user to an extra page after the user signaled interests in receiving updates for a site by clicking a banner. The stand-alone page that the user goes to educates about push (mostly how they will look like) and triggers the push notification permission prompt. The script will wait for the user to grant, deny or dismiss [1] the permission to continue (redirect to previous site).

In Chrome the prompt can be actually dismissed by clicking the X in the dialog. This invokes the callback with default status which means the dialog was dismissed and the site may ask again in the future.

In Firefox the dialog can be closed with the X but it stays available. This permission "purgatory" means that the page can not respond to the users action and idles until the user cancels the dialog by clicking the [back] button in the browser or the page interface.

The service provider reported that 31% of users dismiss the permission prompt by clicking the X (56% accept, 13% deny).

I also want to throw in my hypothesis on why this feels off: Users click the X or [Not Now] in permission dialogs not with the intent of re-opening the dialog later, but to actually dismiss the prompt. Do we have telemetry to prove otherwise?

[1]: https://notifications.spec.whatwg.org/#permission-model

	:Harald Kirschner :digitarald Reporter
	Comment 1 • 9 years ago

:edwong to escalate.

Also I remember :mverdi working on permissions and I wonder if this came up.

	Verdi [:verdi] Best to slack me
	Comment 2 • 9 years ago

(In reply to Harald Kirschner :digitarald from comment #1)
> :edwong to escalate.
> 
> Also I remember :mverdi working on permissions and I wonder if this came up.

I think you're right, clicking the X should probably be the same as denying permission but Philipp Sackl is one working on this so NI'ing him.

	Lina Butler [:lina]
	Comment 3 • 9 years ago

FWIW, this affects all permissions prompts, not just push (see bug 675533 for geolocation). I think it's time we revisit our current behavior.

	Andrew Overholt [:overholt]
	Comment 5 • 9 years ago

Bug 675533 has a related discussion.

	Edwin Wong [:edwong]
	Comment 6 • 9 years ago

I've updated MDN to handle the 'default' return value. 
https://developer.mozilla.org/en-US/docs/Web/API/Notification/permission$revision/996561

	Marco Castelluccio [:marco]
	Comment 8 • 9 years ago

I've also seen people dismissing the prompt by clicking somewhere outside the prompt. I don't know how many people do that though.

	Lina Butler [:lina]
	Comment 9 • 9 years ago

The geo case is slightly different because `getCurrentPosition` can call its callback multiple times...so it's possible for the callback to succeed once the user recalls the doorhanger and grants permission. `Notification.requestPermission()` and `pushManager.subscribe()` use promises, so that approach won't work here.

In our case, if we reject the promise when the user dismisses the dialog, we'll also want to remove the UI for recalling the doorhanger, since it won't do anything. As Matt points out in bug 675533, comment 93, that's not OK. At that point, we may as well do this for all permission dialogs (camera, mic, geo, etc; bug 675533, comment 43). But that's a UX question.

FWIW, I think recalling the doorhanger is useful, but not at all discoverable. If I click the "x" or switch to a different tab, the only indication that I can change my mind is a small proxy icon to the left of the URL bar. It's easy to overlook, and there's no indication it's clickable unless I hover over it. The site can't help me, because it's still waiting on the promise. If we changed "x" to reject the promise, the site could tell me, "hey, you need to allow notifications," and provide UI to re-request permission.

	(Currently slow to respond) Philipp Sackl [:phlsa] (Firefox UX) please use needinfo
	Comment 10 • 9 years ago

There has been a whole project on redesigning our permission prompts within the privacy team. One of the goals was to fix exactly that case by requiring a decision (the user could still use the page, but the bubble would stay visible until a decision is made). That's a good thing to do and fixes all kinds of weird states and ambiguities that people end up in right now.

Javaun, do you know what the schedule for that is? I think it has shifted a couple of times.

	Bill Walker [:bwalker] [@wfwalker]
	Comment 11 • 9 years ago

(In reply to Philipp Sackl [:phlsa] (Firefox UX) please use needinfo from comment #10)
> There has been a whole project on redesigning our permission prompts within
> the privacy team. One of the goals was to fix exactly that case by requiring
> a decision (the user could still use the page, but the bubble would stay
> visible until a decision is made). That's a good thing to do and fixes all
> kinds of weird states and ambiguities that people end up in right now.
> 
> Javaun, do you know what the schedule for that is? I think it has shifted a
> couple of times.

We've got one real site that got 7% opt-in to Firefox web push compared to 37% opt-in to chrome web push, it's reasonable to assume this is a big part of it. We'd like to have something to tell big sites when they run into such disparities.

	Matthew N. [:MattN]
	Comment 12 • 9 years ago

That's not that relevant to this bug which is about what we do when a user dismisses. If you're suggesting that the site isn't being notified of the dismissal so it can immediately re-open the prompt, I can't see how that's good for users.

	Adam Roach [:abr]
	Comment 13 • 9 years ago

(In reply to Bill Walker [:bwalker] [@wfwalker] from comment #11)
> We've got one real site that got 7% opt-in to Firefox web push compared to
> 37% opt-in to chrome web push, it's reasonable to assume this is a big part
> of it. We'd like to have something to tell big sites when they run into such
> disparities.

The attached graph should help visualize the fairly radical difference between user behavior on Firefox versus Chrome. I think it's fair to guess that some substantial portion of the difference in dismissal rate is due to unintended dismissal.

	Matthew N. [:MattN]
	Comment 14 • 9 years ago

I don't see any reason to keep this separate from bug 675533 so duping there.