Compare Firefox behavior to Chrome or Safari when entering fullscreen: 1. Modal alert asking for permission to enter fullscreen. 2. A checkbox to remember decision 3. A notification that we've entered fullscreen 4. fadeout of notification #1 and #2 feel very Windows Vista and aren't consistent with a user-initiated fullscreen command. #2 potentially leaks privacy info in Private Browsing #3 and #4 are all that Chrome displays Safari doesn't display any such prompts but clearly animates the fullscreen transition. This all feels very clunky and adds unnecessary friction. At the very least, we should drop #1 & #2. Bikeshed!

There's an example of the phishing attack being protected against here: http://feross.org/html5-fullscreen-api-attack/ Any changes made here has to get the blessing of the security guys.

(In reply to Chris Pearce (:cpearce) from comment #1) > There's an example of the phishing attack being protected against here: > http://feross.org/html5-fullscreen-api-attack/ Safari doesn't allow that link to go fullscreen at all (no prompts.) Chrome does prompt, but retains the permission bit on the "allow" click. Even in this attack scenario, our UX is worse than other browsers > Any changes made here has to get the blessing of the security guys. Agreed!

(In reply to Jet Villegas (:jet) from comment #2) > (In reply to Chris Pearce (:cpearce) from comment #1) > > There's an example of the phishing attack being protected against here: > > http://feross.org/html5-fullscreen-api-attack/ > > Safari doesn't allow that link to go fullscreen at all (no prompts.) Doesn't Safari only allow fullscreen on <video> elements? A carefully crafted video could in theory still be used to phish a login. > Chrome does prompt, but retains the permission bit on the "allow" click. > > Even in this attack scenario, our UX is worse than other browsers Define "worse"? ;) I think our UX is better as the forgiveness-dialog is more obvious in our UX, and our prompt prevents interaction with the page, whereas Chrome's doesn't. If a user is not paying attention, they could miss Chrome's forgiveness-dialog, and enter their credentials and get phished. That's not possible with our UX.

(In reply to Chris Pearce (:cpearce) from comment #3) > Define "worse"? ;) > > I think our UX is better as the forgiveness-dialog is more obvious in our > UX, and our prompt prevents interaction with the page, whereas Chrome's > doesn't. If a user is not paying attention, they could miss Chrome's > forgiveness-dialog, and enter their credentials and get phished. That's not > possible with our UX. A good compromise may be to relax the check for <video> going full-screen. That's the use-case where we really want to reduce friction.

You mostly care about YouTube right? Relaxing the <video> case won't help with YouTube. On Desktop YouTube has their own video controls rendered over top of the video. So their <video> must reside inside a <div> or somesuch along with their controls. So YouTube would need to be requesting fullscreen on a <div> or somesuch that contains a <video>, not on the <video> itself. I think relaxing the prompt for a <div> containing a <video> is dangerous, as malicious script could include a <video> to avoid the prompt showing, and then remove the video as soon as it was in fullscreen and then phish without warning. We could include a second, stronger whitelist for domains that we trust, like (say) YouTube.com, Vimeo, etc. When sites are in the second whitelist, we could either not show the "you've entered fullscreen" prompt, or only show the notification, and not the forgiveness-prompt. That's vulnerable to being MITM'd, but to be honest once you've been MITM'd script doesn't need to use fullscreen to be pwn you...

(In reply to Chris Pearce (:cpearce) from comment #5) > You mostly care about YouTube right? Relaxing the <video> case won't help > with YouTube. Right, I think we're OK for youtube. I'm thinking about the long-tail of video sites here, and private browsing use cases. > We could include a second, stronger whitelist for domains that we trust, > like (say) YouTube.com, Vimeo, etc. I like this idea a lot. Can we get by with seeding the fullscreen permissions database with sites we know about, or do we need a separate second whitelist?

(In reply to Jet Villegas (:jet) | PTO until Jan. 5 from comment #6) > > We could include a second, stronger whitelist for domains that we trust, > > like (say) YouTube.com, Vimeo, etc. > > I like this idea a lot. Can we get by with seeding the fullscreen > permissions database with sites we know about, or do we need a separate > second whitelist? That depends on how we want to whitelist/behave. If we want to behave as if the user has already marked the super-whitelisted sites as being allowed to always go fullscreen (i.e. we still want to show the "$domain entered fullscreen" message for 4 seconds after entering fullscreen on these sites) then we can just pre-populate the permissions database. This approach is probably the safest and easiest. If we want to have *no* fullscreen prompt or entered-fullscreen notification for the super-whitelist, then we'd need a second whitelist hardcoded somewhere (probably in browser-fullScreen.js I'd expect).

Building in a whitelist rubs me the wrong way: * It lets us pretend we've solved the UX problem by hiding it from some en-US users. * It gives attackers a leg up (XSS any of these 30 video sites). * It entrenches existing video sites, allowing them to continue to abuse their dominance. * We'd only be able to whitelist YouTube, because the others refuse to support https. Other possibilities for improving UX in non-attack cases: * Default to remembering * Remove the checkbox? (like Google Chrome) * Only for https? * Improve the animation * Show the prompt/warning as soon as the animation starts * Have a separate "full screen for video" mode that prevents alpha keyboard input My arguments against: https://wiki.mozilla.org/Gecko:FullScreenAPI#Discussion_2011-04-21 My arguments for: Bug 716107 comment 5. * Ditch the permission prompt entirely. Instead, show a thin URL bar at the top of the screen for the first 3 seconds and whenever the user interacts with the page. For videos, this should be fine. For games, it shifts the user interaction from "click the 'allow' button" to "click the 'hide' button, if you want".

Or we could make full-screen actually be user-initiated, by moving the full-screen button from the video element to the toolbar. (For legacy sites, we'd highlight the toolbar button when the in-content button is pressed.)

(In reply to Jet Villegas (:jet) from comment #0) > 1. Modal alert asking for permission to enter fullscreen. > 2. A checkbox to remember decision > 3. A notification that we've entered fullscreen > 4. fadeout of notification > > #1 and #2 feel very Windows Vista and aren't consistent with a > user-initiated fullscreen command. > > #2 potentially leaks privacy info in Private Browsing > > #3 and #4 are all that Chrome displays It's not true that we do 1-4. EITHER we do 1 and 2, OR you have remembered the permission and we do 3 and 4. Never all four. The only difference between Chrome and Firefox are a. the visual appearance of the prompt b. whether events hit the page while the prompt is displayed c. whether the "allow" permission is remembered automatically or requires ticking a checkbox Those are important differences, but it's not at all true chrome only does 3 and 4. Bringing up private browsing is a distraction. We've dealt with it, Chrome has dealt with it, we have to deal with it in all sorts of features. Personally I am annoyed chrome assumes a one-time grant means it's A-OK forever; I'm especially alarmed that is true for non-TLS sites. At least they do have relatively discoverable UI for revoking the permission later if you realize what happened. We have UI for it too, a tab on the Page Info dialog, but I doubt users would think to look there plus it takes more clicks to get to than Chrome's. I don't count about:permissions because it's completely unreachable/undiscoverable in our UI. Still, it'd be nice to make the "remember" choice easier when users want to. Maybe we could pre-check the remember box on https:// sites? That would be functionally equivalent to what Chrome does. Or we could mix up the buttons altogether: * Put one of those "x in a circle" close buttons in the top right like you see on web overlay ads. Clicking that is effectively the "allow" button. * the buttons inside the overlay are "Deny" and "Always allow fullscreen for foo.org" Alternately the "close overlay" circle-x could be the deny (probably more consistent behavior to hitting ESC) and the dialog itself could have allow/always-allow buttons. Saves users a click for the always-allow case, removes a whole checkbox and sentence they have to parse and understand, and saves space. Either redesign loses access to "always deny" but how many people use that? If a site is that annoying do they go back? The option is always available on either of the permissions dialogs. Our notice is big and plain (ugly?), Chrome's is too unobtrusive. A proper designer (i.e. not us engineers) might come up with something in between that looks nice but isn't going to get missed like chrome's. We could get away with less obtrusive (than our current design, not as far as Chrome's) because we block events getting to the page until the user has discovered and dealt with the prompt.

If we eventually decide to keep the system transition effect on Mac, we probably can disable the permission asking on that platform, because it is obvious for user that we are going to fullscreen.

With bug 1160017, we do not ask for approval for fullscreen anymore. Mark this as fixed.