Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Web compat issue with permissions.query() in non-persistent permission models #928

Closed
jan-ivar opened this issue Feb 3, 2023 · 2 comments

Comments

@jan-ivar
Copy link
Member

jan-ivar commented Feb 3, 2023

Most video conferencing sites offer a smoother user experience to returning Chrome users than to returning users in other browsers, because they basically ignore past non-persisted permissions entirely. IOW, that users in Safari or Firefox granted camera last time they used the site, and the time before that, counts for nothing apparently.

Anything short of "granted" persisted permission is ignored, and seems treated as a user retraining problem. To illustrate, this:

const perm = await navigator.permissions.query({name: "camera"});
if (perm.state == "prompt") {
  nagTheUserAboutEnablingPermission();
}

...causes diverging user experiences in browsers that persist permission from those that don't. E.g.:

If you're a whereby.com user in Chrome, you're forgiven for not remembering this page, because you probably only ever saw it once:

image

In contrast, returning users in Safari and Firefox (by default) see it every meeting. This new-user slow lane requires two extra clicks to get into the meeting (even with both camera and microphone off, which in theory shouldn't require any permission at all). This is a poor experience that might push users into escalating permissions to the site, which is bad for privacy. A single click (in the browser's permission prompt) should suffice for returning users.

The permissions API isn't helping

The permissions API doesn't care about past non-persisted permissions either. It only exposes current user agent state, when it should be focused on abstracting what sites need, in a manner that doesn't require sites to write different code per user agent.

The measurable discrepancy in end-user experience across user agents on this topic shows that sites have low patience for differences among user agents, and that APIs that merely expose those differences are insufficient to ensure good end-user outcomes.

Proposal

Mozilla would like to implement query in Firefox (bug 1609427), but we're concerned the API's lack of recognition of past non-persisted permissions would regress behavior for Firefox users once sites feature-detect this and apply their logic (which was written for Chrome, and won't fit Firefox's non-persisted permission model).

We'd like to propose this addendum to permission descriptor type:

  • "If the descriptor does not have a deviceId, and permission state is "prompt", User Agents that offer non-persisted permissions MAY return "granted" if the user granted device access to this origin the last time this origin requested it."

This would let Firefox implement query in a way that values past non-persistent permissions, for a smoother returning-user experience closer to Chrome's.

IOW, sites that make blanket queries would get "prompt" for first-time users, and "granted" for returning users that haven't "denied", just like in Chrome (even though Firefox would still prompt). Since Firefox's permission prompt doesn't perma-block on "no", we see no real risk to sites from this. We think this is a good default for Firefox.

We do recognize this is ultimately a site's decision, and sites with more stringent requirements (e.g. tele-visit sites), can get the current permission state of individual devices directly (which would still return "prompt"):

const perm = await navigator.permissions.query({name: "camera", deviceId: localStorage.lastUsedDeviceId});
if (perm.state == "prompt") {
  nagTheUserAboutEnablingPermission(); // nags outside Firefox's "Temporarily Allowed" 60 minute grace period
}

This seems more web compatible by flipping the default: no need to implore sites to use deviceId to make Firefox work. Instead, only sites that aren't satisfied with Firefox's default behavior need use deviceId.

@dontcallmedom-bot
Copy link

This issue was discussed in WebRTC Feb 2023 Meeting – (Issue #928 🎞︎)

@jan-ivar
Copy link
Member Author

This is OBE by w3c/permissions#414 (comment) and #968.

@jan-ivar jan-ivar closed this as not planned Won't fix, can't repro, duplicate, stale Feb 14, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants