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"](https://robert.ocallahan.org/2011/06/permissions-for-web-applications_30.html?showComment=1309484729000&m=1) model, forcing apps to engineer prompting "up front". 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): 1. at install (old android) 2. once up-front (Chrome) 3. in context (Firefox)
Bug 957558 Comment 5 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
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"](https://robert.ocallahan.org/2011/06/permissions-for-web-applications_30.html?showComment=1309484729000&m=1) 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): 1. at install (old android) 2. once up-front (Chrome) 3. in context (Firefox)