Permission prompt for camera combined with fullscreen fails UI-wise
Categories
(Firefox :: Site Permissions, defect)
Tracking
()
People
(Reporter: annevk, Unassigned)
References
Details
Attachments
(2 files)
ChromeFullscreenGum.png
|
||
Comment 1•3 years ago
|
||
Requires https now 🙂: https://dontcallmedom.github.io/web-permissions-req/tests/all.html
This is still an issue, and seems overdue for a fix. Workarounds are not great as seen in bug 1745575. Changing component for triage.
Paul, is this something that perhaps has gotten simpler with the latest front-end?
|
|
||
Comment 3•3 years ago
|
||
How Chrome shows it.
|
||
Comment 4•3 years ago
|
||
Since bug 1522120 we (deliberately) exit full screen when showing site permission prompts (including WebRTC prompts). Is this the issue you're describing?
Related to this is bug 1355000, where we don't anchor the PopupNotification correctly after exiting full screen.
I'm not sure what this bug is about specifically, since it's older than bug 1522120 and doesn't have a description.
|
|
||
Comment 5•3 years ago
•
|
||
Maybe it never worked properly? Regardless, I assumed it was about prompts popping the user out of fullscreen when I dup'ed bug 1745575 here. Happy to discuss in either bug.
Since bug 1522120 we (deliberately) exit full screen when showing site permission prompts (including WebRTC prompts). Is this the issue you're describing?
Yes. While the rationale in bug 1522120 comment 0 makes sense to me for add-ons, as a security measure against social engineering of malicious installs, I don't see the same risk with camera/mic prompts (which are for temporary permission by default). Can we make an exception for gUM?
The issue is there are valid use cases for fullscreen video conferencing, as shown in bug 1745575, and popping out of it due to prompts defeats our "Permissions In Context" model, forcing apps to engineer prompting "up front". It's also a Chrome parity web compat issue.
These kinds of "up front" engineering in apps usually turns out bad for Firefox, because it tends to assume Chrome's persistent permission model (2 below), something apps can get out of the way once, often deserving of its own "priming page" to not get permanently blocked in Chrome.
This then ends up conflating Firefox users with first-time users, taking them through a patronizing "slow-lane" of priming ("here's why you need to give us access to your camera and not permanently block us, see?")
Permission models (from least to most private):
- at install (old android)
- once up-front (Chrome)
- in context (Firefox)
|
|
||
Comment 6•3 years ago
•
|
||
I think for gUM prompts there is a similar risk. Sites may try to trap less experienced users in full screen and get them to allow access to camera / mic or start a screen share. Currently we can't really show permissions prompts in full screen without this spoofing risk.
For scenarios like in Bug 1745575, could the website simply call gUM, pop out of full screen and enter full screen again once the prompt has been accepted? This way the context of the permission request would be clear and no additional click is required. If there is already a temporary permission set, gUM will succeed without a prompt and Firefox will not leave full screen.
I've created a demo page here: https://ivy-bald-headlight.glitch.me/
Edit: Bug 1355000 makes the flow a bit confusing, because the PopupNotification used for the permission request looses its anchor point when leaving full screen. This would be worth prioritizing if this is a common scenario.
|
||
Comment 7•3 years ago
|
||
Paul, in fact, your demo page proves the underlying UX problem perfectly.
Try intentionally waiting a few seconds before accepting the camera permission. You will get the camera permission, but the user gesture token will expire and the fullscreen request is denied with a TypeError.
|
|
||
Comment 8•3 years ago
|
||
(In reply to Will Morgan from comment #7)
Paul, in fact, your demo page proves the underlying UX problem perfectly.
Try intentionally waiting a few seconds before accepting the camera permission. You will get the camera permission, but the user gesture token will expire and the fullscreen request is denied with a TypeError.
You're right. Looks like accepting the gUM request does not renew the user activation. We do this for other permission requests, like the Storage Access API (Bug 1732919).
|
|
||
Comment 9•3 years ago
|
||
Could we solve this by making the user pushing the Allow button count as transient activcation iff the getUserMedia call that triggered it was itself invoked during transient activation?
This would reduce side-effects of prompting.
|
|
||
Comment 10•3 years ago
|
||
I like that idea, but I'm not sure how well it would align spec wise.
Anne, do you think we could add a similar mechanism to the getUserMedia prompts, like we added recently for the storage access API (Bug 1732919)? We could do it similarly to the rSA case and only renew activation if the permission request is accepted.
This way sites could use user activation gated APIs after users accept the prompt, even if the original user activation has already timed out.
|
Reporter | |
Comment 11•3 years ago
|
||
This bug was mainly about the UI falling apart somewhat. E.g., the dialog ending up in the wrong position.
I think allowing a second activation is reasonable, though perhaps we need to scope what the second activation can be used for. E.g., if it is used to trigger another dialog that might end up being confusing. (With the user potentially hitting Allow twice in a row, with the second time for something they did not plan to grant.)
|
|
||
Comment 12•3 years ago
|
||
Could we solve this by making the user pushing the Allow button count as transient activcation iff the getUserMedia call that triggered it was itself invoked during transient activation?
This would align with Chrome's "User Activation" API, accessible via navigator.userActivation.
This GitHub issue from WhatWG suggests the web app should prompt the user for camera access first, play underlying video element, then enter fullscreen. In my app, if I follow that strategy, it works in Chrome.
In Firefox, it generally works, unless I intentionally delay allowing the camera prompt. In that case, requestFullScreen fails with "TypeError: Fullscreen request denied".
In Safari on desktop, the requestFullscreen promise never fulfils or rejects, but I don't think that's intentional. I'll investigate the Safari issue some more and raise the ticket on their bug tracker if necessary.
In summary, f the interaction to allow the permission would renew the interaction, then we've aligned things successfully with Chrome -- and WhatWG.
|
|
Reporter | |
Comment 13•3 years ago
|
||
Well, I'm pretty certain that the behavior in Chrome is not defined as part of getUserMedia(). So what you observe through navigator.userActivation sounds like non-standard behavior. (Modifying the standard seems somewhat reasonable, modulo the double-dialog risk I raised above.)
|
|
||
Comment 14•3 years ago
|
||
Thanks Anne!
(In reply to Anne (:annevk) from comment #11)
This bug was mainly about the UI falling apart somewhat. E.g., the dialog ending up in the wrong position.
I see, so Bug 1355000 is actually a dupe of this bug.
I think allowing a second activation is reasonable, though perhaps we need to scope what the second activation can be used for. E.g., if it is used to trigger another dialog that might end up being confusing. (With the user potentially hitting Allow twice in a row, with the second time for something they did not plan to grant.)
This confusing behavior is already possible to create in Firefox and Chromium, by simply creating multiple permission requests at the same time (without waiting for promise resolution first). Both browsers will queue the permission panels.
|
|
Reporter | |
Comment 15•3 years ago
|
||
So if that's the case doesn't that mean that creating permission requests shouldn't consume the activation?
|
|
||
Comment 16•3 years ago
|
||
(In reply to Anne (:annevk) from comment #15)
So if that's the case doesn't that mean that creating permission requests shouldn't consume the activation?
I don't think it currently does. That's why sites can create multiple requests from one activation. The issue described in comment 7 is an expired user activation (timeout).
|
|
||
Comment 17•3 years ago
•
|
||
(In reply to Will Morgan from comment #12)
This GitHub issue from WhatWG suggests the web app should prompt the user for camera access first, play underlying video element, then enter fullscreen. In my app, if I follow that strategy, it works in Chrome.
From my testing, using https://ivy-bald-headlight.glitch.me/, if I wait long enough before accepting the prompt, Chromium will behave similar to Firefox and not grant the full screen request. Do you have a working example? Also, could you please link the GitHub issue you mentioned? Thanks!
I get the following error in Chromium:
Failed to execute 'requestFullscreen' on 'Element': API can only be initiated by a user gesture.
|
|
||
Comment 18•3 years ago
|
||
Paul, you're right:
From my testing, using https://ivy-bald-headlight.glitch.me/, if I wait long enough before accepting the prompt, Chromium will behave similar to Firefox and not grant the full screen request. Do you have a working example? Also, could you please link the GitHub issue you mentioned? Thanks!
I can replicate the same in Chrome. The difference in Chrome is that it currently exposes device labels which means it's easier to tell if we already have camera permission or not, which is a different but related issue - and the action is on Chrome to become standards compliant.
The GitHub issue I meant to link in #c12 is here: https://github.com/whatwg/fullscreen/issues/152#issuecomment-494840412
|
||
Updated•2 years ago
|
|
|
||
Comment 19•2 years ago
|
||
Sorry, I lost track of this. Judging from comment 11 this is a duplicate so I'm marking it as such. This bug is older but the other one has more context.
The user activation changes should be discussed on GitHub and we can file a new bug when we reach consensus. Also see https://github.com/web-platform-tests/wpt/issues/36481 which is sort of related.
Description
•