28460 2015-04-10 05:03:27 +0000 Request fullscreen on both iframe and elements inside it could cause undesired result 2015-10-07 11:52:09 +0000 1 1 1 Unclassified WebAppsWG Fullscreen unspecified All All RESOLVED FIXED P2 normal --- 1 xidorn+w3c annevk bugs mike philipj public-webapps r12f.code public-webapps-bugzilla oldest_to_newest 119420 0 xidorn+w3c 2015-04-10 05:03:27 +0000 In the current spec, the "collect ancestors" function returns a list of documents whose fullscreen element stack consist of one element, and then those documents exit from fullscreen in the last step of exitFullscreen() method. I know it is defined this way so that iframes outside automatically exit when we exit the only fullscreen element in it, just like how they were automatically pushed to the stack. But this could cause undesired problem if author explicitly calls requestFullscreen() on an iframe element, then call the same method on some element inside. For example, if we have tree like: iframe #a | +- div #b and follow the steps: 1. call a.requestFullscreen() 2. call b.requestFullscreen() 3. call a.contentDocument.exitFullscreen() This will cause the fullscreen be fully exited, because the only element in the fullscreen element stack of document inside #a is being popped. This could really surprise author, as they could sometimes want to make iframe itself fullscreen. To fix this issue, I propose we change the first step of requestFullscreen() to: If the context object has nested browsing context, let pending be the documentElement of the nested document, otherwise, let pending be the context object. This could make things a little surprising that calling requestFullscreen() on an iframe then calling exitFullscreen() on its contentDocument could exit fullscreen. But I think it should be fine as it doesn't add much complexity while fixes a more significant undesired behavior. 122061 1 philipj 2015-07-15 12:55:26 +0000 Is this problem big enough to try fixing? For my own part, if it is fixed, I think it ought to be by having a flag on iframe elements in the top layer stack which means "this was added explicitly, don't exit implicitly". 122199 2 annevk 2015-07-18 06:16:14 +0000 Xidorn, is Philip's approach okay with you? I'm also not entirely sure this warrants fixing, but I guess it makes the whole setup slightly more consistent. 122201 3 xidorn+w3c 2015-07-18 06:31:28 +0000 That approach probably makes the most sense. I don't know whether it is worth solving, but it seems to me Trident does it in a more sensible way than the spec on this issue. 122202 4 philipj 2015-07-18 07:13:00 +0000 (In reply to Xidorn Quan from comment #3) > That approach probably makes the most sense. I don't know whether it is > worth solving, but it seems to me Trident does it in a more sensible way > than the spec on this issue. Huh, Trident already does something clever here? Better ask them precisely what it is and use that if it's good enough. 122203 5 philipj 2015-07-18 07:16:15 +0000 I've emailed Ali Alabbas at Microsoft about this. 122286 6 r12f.code 2015-07-24 23:09:36 +0000 Hi Xidorn and Philip, I am a dev from Microsoft IE team and now working on fullscreen area. Nice to you meet you guys. Philip’s approach looks good to me. Trident is now doing something very similar to avoid this issue. The explicitly added elements are marked differently in trident. Thanks, Riff 122292 7 annevk 2015-07-27 07:04:22 +0000 https://github.com/whatwg/fullscreen/commit/079dcf4bacd976359b412522dd8e5f75b7ac4a1e Thanks Riff! 122451 8 philipj 2015-08-04 12:02:02 +0000 (In reply to Anne from comment #7) > https://github.com/whatwg/fullscreen/commit/ > 079dcf4bacd976359b412522dd8e5f75b7ac4a1e > > Thanks Riff! These changes look good to me. Do they pedantically match the implementation in Edge, Riff? (That would be surprising, but any differences are worth knowing.) 122476 9 r12f.code 2015-08-06 00:06:14 +0000 (In reply to Philip Jägenstedt from comment #8) > (In reply to Anne from comment #7) > > https://github.com/whatwg/fullscreen/commit/ > > 079dcf4bacd976359b412522dd8e5f75b7ac4a1e > > > > Thanks Riff! > > These changes look good to me. Do they pedantically match the implementation > in Edge, Riff? (That would be surprising, but any differences are worth > knowing.) Yes, Philip. No surprises here. The way we track the explicitly added elements in Trident and Edge are exactly the same. 123591 10 bugs 2015-10-07 11:37:50 +0000 So this deals with iframes only. Should also <object> and <frame> be handled the same way (though, <frame> is rather deprecated.) Feels odd if <iframe> and <object> behave differently. 123593 11 xidorn+w3c 2015-10-07 11:47:50 +0000 (In reply to Olli Pettay from comment #10) > So this deals with iframes only. Should also <object> and <frame> be handled > the same way (though, <frame> is rather deprecated.) > Feels odd if <iframe> and <object> behave differently. It doesn't seem to me any document inside <frame> or <object> should ever be able to enter fullscreen. According to the spec, an element can enter fullscreen only when its document has "fullscreen enabled flag" set [1], however that flag is only set for the topmost document and document inside <iframe> with allowfullscreen attribute set [2]. [1] https://fullscreen.spec.whatwg.org/#fullscreen-element-ready-check [2] https://fullscreen.spec.whatwg.org/#fullscreen-enabled-flag 123594 12 philipj 2015-10-07 11:52:09 +0000 (In reply to Xidorn Quan from comment #11) > It doesn't seem to me any document inside <frame> or <object> should ever be > able to enter fullscreen. That is correct, and I've previously even removed some support for <frame> from Blink.