This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
This was was cloned from bug 16709 as part of operation convergence. Originally filed: 2012-04-12 07:35:00 +0000 Original reporter: Anne <annevk@annevk.nl> ================================================================================ #0 Anne 2012-04-12 07:35:41 +0000 -------------------------------------------------------------------------------- As discussed on the WHATWG list and elsewhere, HTML needs a few updates to make Fullscreen "work" (and better): * Define that the "fullscreen enabled flag" is set for top-level browsing contexts. * Define that the "fullscreen enabled flag" is set for nested browsing contexts if their browsing context container (including ancestors) has a allowfullscreen="" attribute set. (That attribute needs to be defined too.) * "fully exit fullscreen" when navigating. * onfullscreenchange and onfullscreenerror event handlers ================================================================================ #1 Anne 2012-04-12 07:36:04 +0000 -------------------------------------------------------------------------------- *** Bug 16452 has been marked as a duplicate of this bug. *** ================================================================================ #2 Anne 2012-04-12 07:38:13 +0000 -------------------------------------------------------------------------------- Hixie, I'm setting this to critical so browsers can start removing the silly prefixes sooner. ================================================================================
Pointer Lock [1] will use the same method as Fullscreen. I also propose that the iframe attribute sandbox="allow-fullscreen" and or sandbox="allow-pointer-lock" be used instead of a new attribute allowfullscreen. This implies the following as existing prefixed implementations already use prefixallowfullscreen: - non sandbox iframes are blocked from using Fullscreen (FS) or Pointer Lock (PL). - legacy prefixed attributes (e.g. prefixallowfullscreen) may continue to allow non sandbox iframes to support FS/PL, but are not included in the HTML spec. - sandbox iframes block FS/PL unless the appropriate allow- values are included. [1] http://dvcs.w3.org/hg/pointerlock/raw-file/default/index.html
Why would we want to prevent non-sandboxed iframes from going full-screen?
(In reply to comment #2) > Why would we want to prevent non-sandboxed iframes from going full-screen? Full screen is already prevented, unless an attribute is added. Full screen is a security threat and is entered without requiring user confirmation first. I ask: if an attribute is already required to permit this for security reasons, why not use a sandbox attribute and any other allow- values as necessary?
I should add, though, that I'm not familiar with why non sandboxed iframes were deemed to require an attribute. I would personally also accept an argument that developers should use sandbox when they wish to restrict functionality and that FS and PL could be acceptable on non sandboxed iframes without any additional attribute.
(In reply to comment #2) > Why would we want to prevent non-sandboxed iframes from going full-screen? Paranoia. Hitherto, a page could host a cross-origin IFRAME and assume the framed content can't display outside the IFRAME. With fullscreen, it can. I thought we should not break that assumption. One could make the argument that the framed content can display outside the IFRAME, using Flash to go fullscreen, but I'm leery of "reductio ad Flash" arguments.
My question was why would we want to make it impossible for non-sandboxed iframes to be allowed to go fullscreen, if we are making it possible to allow sandboxed fromes to go fullscreen. I wasn't suggesting that we make it possible for any non-sandboxed iframe to go fullscreen, which to me seems like an obviously bad idea for the reasons roc gave. Anne: What is the "fullscreen enabled flag"? What do I point to for the definition of that? URL? scheib: What do I need to do to provide the integration points for pointer lock? If you could give me something like Anne's note in #0, that would be ideal (with all the flag names, etc).
Pointer lock seems appropriate to enable by default on non-sandboxed iframes, as the reason roc gave for fullscreen being disabled by default does not apply to pointer lock. Pointer lock should be disabled in sandboxed iframes unless explicitly permitted, sandbox="allow-pointer-lock" is appropriate for doing so, and seems preferable vs mimicing allowfullscreen without the same justification. ian: Edits along these lines: http://dev.w3.org/html5/spec/origin-0.html#sandboxing + "The sandboxed pointer lock flag + This flag prevents content from using the Pointer Lock API" with link to http://www.w3.org/TR/pointerlock/ ... "When the user agent is to parse a sandboxing directive ..." + "The sandboxed pointer lock flag, unless tokens contains the allow-pointer-lock keyword"
Ok so pointer lock is not to be the same as allowfullscreen? If so, please file a separate bug for the pointer-lock stuff: http://whatwg.org/newbug
(In reply to comment #8) > Ok so pointer lock is not to be the same as allowfullscreen? If so, please file > a separate bug for the pointer-lock stuff: http://whatwg.org/newbug New issue https://www.w3.org/Bugs/Public/show_bug.cgi?id=18647 I do not believe we should introduce an allowpointerlock because there is no need for a non sandboxed iframe, and the consistency with other sandbox items seems preferable vs yet another new attribute.
Pointer lock sounds like an incredibly bad idea to me. Suppose that, as a user, I have no interest in any of the use cases at http://www.w3.org/TR/pointerlock/#use-cases , and care much more about security. Will I be able to switch off pointer lock globally? Will the spec say that such a preference MUST be provided?
(In reply to comment #10) > Pointer lock sounds like an incredibly bad idea to me. Suppose that, as a user, > I have no interest in any of the use cases at > http://www.w3.org/TR/pointerlock/#use-cases , and care much more about > security. Will I be able to switch off pointer lock globally? Will the spec say > that such a preference MUST be provided? David, this comment is off topic. Let me address it briefly and if you'd like to follow up please use your preference of public-webapps@w3.org, whatwg@lists.whatwg.org, and scheib <scheib@chromium.org>. Your security is entrusted in the browser you use. The specification makes it clear that user agents may have different approaches to how they provide that. Chrome has an implementation which you can try now in the chrome canary [1], a good example site is [2]. You will find that the feature is not available until permitted by you for each origin that attempts to use it. You are also able to disable the feature globally in chrome settings, search for mouse: find it in the Privacy, Content settings, Mouse cursor, Do not allow any site to disable the mouse cursor. Firefox also has an implementation already in stable builds (e.g. 14 has it). There it is restricted to only when you allow a page to enter fullscreen (an actual security threat). I'm less familiar, and uncertain if they have a global option. [1] https://tools.google.com/dlpage/chromesxs/ [2] http://media.tojicode.com/q3bsp/
http://dvcs.w3.org/hg/fullscreen/raw-file/tip/Overview.html#fullscreen-enabled-flag It's unset by default, so you need to set it in the HTML specification when the conditions are right. (E.g. attribute is set, top-level browsing context, etc. see comment 0.)
*** This bug has been marked as a duplicate of bug 18840 ***