This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 28460 - Request fullscreen on both iframe and elements inside it could cause undesired result
Summary: Request fullscreen on both iframe and elements inside it could cause undesire...
Status: RESOLVED FIXED
Alias: None
Product: WebAppsWG
Classification: Unclassified
Component: Fullscreen (show other bugs)
Version: unspecified
Hardware: All All
: P2 normal
Target Milestone: ---
Assignee: Anne
QA Contact: public-webapps-bugzilla
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-04-10 05:03 UTC by Xidorn Quan
Modified: 2015-10-07 11:52 UTC (History)
5 users (show)

See Also:


Attachments

Description Xidorn Quan 2015-04-10 05:03:27 UTC
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.
Comment 1 Philip Jägenstedt 2015-07-15 12:55:26 UTC
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".
Comment 2 Anne 2015-07-18 06:16:14 UTC
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.
Comment 3 Xidorn Quan 2015-07-18 06:31:28 UTC
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.
Comment 4 Philip Jägenstedt 2015-07-18 07:13:00 UTC
(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.
Comment 5 Philip Jägenstedt 2015-07-18 07:16:15 UTC
I've emailed Ali Alabbas at Microsoft about this.
Comment 6 Riff Jiang 2015-07-24 23:09:36 UTC
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
Comment 8 Philip Jägenstedt 2015-08-04 12:02:02 UTC
(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.)
Comment 9 Riff Jiang 2015-08-06 00:06:14 UTC
(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.
Comment 10 Olli Pettay 2015-10-07 11:37:50 UTC
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.
Comment 11 Xidorn Quan 2015-10-07 11:47:50 UTC
(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
Comment 12 Philip Jägenstedt 2015-10-07 11:52:09 UTC
(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.