- From: <bugzilla@jessica.w3.org>
- Date: Fri, 10 Apr 2015 05:03:27 +0000
- To: public-webapps-bugzilla@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=28460
Bug ID: 28460
Summary: Request fullscreen on both iframe and elements inside
it could cause undesired result
Product: WebAppsWG
Version: unspecified
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P2
Component: Fullscreen
Assignee: annevk@annevk.nl
Reporter: quanxunzhen@gmail.com
QA Contact: public-webapps-bugzilla@w3.org
CC: mike@w3.org, public-webapps@w3.org
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.
--
You are receiving this mail because:
You are the QA Contact for the bug.
Received on Friday, 10 April 2015 05:03:28 UTC