Bugzilla

As Martin said, this is something that we've been planning to do for quite some time. However, as always, the overall situation is a little more complex than the headline might suggest and this project definitely needs someone to own it and push it forward.

I'd like to provide a bit of background to this. The main complication is, of course, web compat. Currently, not even a single percent of websites on beta are requesting the desktop-notification permission with user gesture (https://mzl.la/2TzqOIc). If our measurements are correct, that's a breakage rate of 99%, which, as I understand, would be an unprecedented amount of breakage.

I would really like to do this, however, and push forward on restricting other highly used permission prompts as well. I added the telemetry years ago in preparation/anticipation of this change (and telemetry on HTTPS/third party checks as well).

We had some conversations about this in Orlando, and we came up with a few suggestions:

- When blocking permission requests, we should give users a subtle UI hint that we've done so, and provide them with an option to revert their decision.

- To that extent, we were planning to work out some amendment to the Permissions API that e.g. provides an event to let websites know when it is allowed to prompt users for permission again.

- Thirdly (and maybe most crucially), we have really good Telemetry on a) permission request rate and b) user interaction on doorhangers (https://mzl.la/2TzqOIc). I'm confident that our goal in this work comes down to increasing the percentage of users who reply "Allow" to a prompt (which means it appeared in the right context) while keeping the total number of prompts high (thus allowing a large group of developers to use the API in a good manner). Both are easily measurable. 
To this extent, we could develop a shield study that flips prefs to enable a number of restrictions on permission prompts (such as user gesture, storageAccessAPI permission, etc.) and measure which strikes the best (or maybe an appropriate) balance.

Again, this all would take quite a bit of time and someone to drive it. I was trying to get some resourcing on this, and some additional help might allow us to move even faster.
  
With that said, if someone can come to the decision that we should "just do it" as Safari has done, I'm happy to be part of that. Given the potential breakage this decision could be quite impactful to Firefox as a project and the Mozilla Corporation strategy, so I believe it may be something for the FTLM (https://wiki.mozilla.org/Modules/Firefox_Technical_Leadership)

Thoughts?

As Martin said, this is something that we've been planning to do for quite some time. However, as always, the overall situation is a little more complex than the headline might suggest and this project definitely needs someone to own it and push it forward.

I'd like to provide a bit of background to this. The main complication is, of course, web compat. Currently, not even a single percent of websites on beta are requesting the desktop-notification permission with user gesture (https://mzl.la/2TzqOIc). If our measurements are correct, that's a breakage rate of 99%, which, as I understand, would be an unprecedented amount of breakage.

I would really like to do this, however, and push forward on restricting other highly used permission prompts as well. I added the telemetry years ago in preparation/anticipation of this change (and telemetry on HTTPS/third party checks as well).

We had some conversations about this in Orlando, and we came up with a few suggestions:

- When blocking permission requests, we should give users a subtle UI hint that we've done so, and provide them with an option to revert their decision.

- To that extent, we were planning to work out some amendment to the Permissions API that e.g. provides an event to let websites know when it is allowed to prompt users for permission again.

- Thirdly (and maybe most crucially), we have really good Telemetry on a) permission request rate and b) user interaction on doorhangers (https://mzl.la/2Bi57VI). I'm confident that our goal in this work comes down to increasing the percentage of users who reply "Allow" to a prompt (which means it appeared in the right context) while keeping the total number of prompts high (thus allowing a large group of developers to use the API in a good manner). Both are easily measurable. 
To this extent, we could develop a shield study that flips prefs to enable a number of restrictions on permission prompts (such as user gesture, storageAccessAPI permission, etc.) and measure which strikes the best (or maybe an appropriate) balance.

Again, this all would take quite a bit of time and someone to drive it. I was trying to get some resourcing on this, and some additional help might allow us to move even faster.
  
With that said, if someone can come to the decision that we should "just do it" as Safari has done, I'm happy to be part of that. Given the potential breakage this decision could be quite impactful to Firefox as a project and the Mozilla Corporation strategy, so I believe it may be something for the FTLM (https://wiki.mozilla.org/Modules/Firefox_Technical_Leadership)

Thoughts?