You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
...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:
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).
"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"):
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.
The text was updated successfully, but these errors were encountered:
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:...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:
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:
"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"
):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 usedeviceId
.The text was updated successfully, but these errors were encountered: