(In reply to Johann Hofmann [:johannh] from comment #2)
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
Hmm, they aren't, but probably not in a way that matters here:
StorageAccessPermissionRequest always passes in false: https://searchfox.org/mozilla-central/rev/152993fa346c8fd9296e4cd6622234a664f53341/dom/base/StorageAccessPermissionRequest.cpp#24
MIDIPermissionRequest always passes in true: https://searchfox.org/mozilla-central/rev/152993fa346c8fd9296e4cd6622234a664f53341/dom/midi/MIDIPermissionRequest.cpp#31
We should probably make ContentPermissionRequestBase() not accept a boolean argument for this and call EventStateManager::IsHandlingUserInput() itself to prevent future mistakes of this type. (It is not clear from Gecko what this boolean ends up being used for...)
, that's a breakage rate of 99%, which, as I understand, would be an unprecedented amount of breakage.
This data looks pretty sad for our users more so than for web developers, since that shows that users receive most of our permission prompts probably without having interacted with the page. :-(
Do we have data on which percentage of notification prompts users say "Allow" to by any chance?
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).
Wrong link (same as the previous one...)?
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.
Overall sounds good.
But I'm curious, why do you think our overall goal should be to increase the percentage of users who reply "Allow" to a prompt? That might convert the project from an annoyance mitigation project (remove the possibility of websites showing permission prompts in scenarios where users will definitely say "Deny" or will ignore the prompt) into a monumentally difficult project with vastly different goals. For example, consider randomjunknews.example/you-clicked-on-this-link-by-accident.html. If while searching for something I come across that page, it can currently show me a notification prompt on load. If we made these prompts require a user gesture it might register a click handler on the body or some such, and if I clicked accidentally somewhere on the page while rushing to hit Back, it can quickly show me the same notification. In both cases my interest as a user is aligned against the interests of the web developer in that I probably never want to receive any messages from the site. Why should we pick a success metric that may be misaligned with the interests of our users?
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)
In the past when moving the geolocation API to secure contexts we've been willing to break ~20% of active call sites https://groups.google.com/d/msg/mozilla.dev.platform/BvcsTpAqIsQ/PjXqf3u3BgAJ. Part of the argument for doing so at the time was that sites that would be broken in Firefox as a result were broken in Chrome and Safari already.
Going forward, I guess over 99% of sites which use notification prompts will be broken in Safari. Although I think the case of the geolocation API is quite different than the notification API, since in the former case chances are that the site may be using the user's location to do something with on the page, but in the latter case users will probably see the result of the breakage later if they continue to use the website and actually want to receive notifications from it. If we have some data on the percentage of users who currently respond "Allow" to these prompts it may be possible to say with more confidence whether they would consider the resulting behaviour as breakage per se.
It would also be interesting to see what Chrome's stance on this issue is.