New issue
Advanced search Search tips

Issue 617369 link

Starred by 3 users

Issue metadata

Status: Available
Owner: ----
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 3
Type: Bug



Sign in to add a comment

Nested fullscreen not exited properly after entering fullscreen for elements in different frames

Project Member Reported by alex...@chromium.org, Jun 4 2016

Issue description

Repro steps:
(1) Go to https://alexmos17.github.io/tests/fullscreen.html
(2) Click "Enter fullscreen for iframe"
(3) Click "Enter fullscreen for div" in the fullscreened iframe
(4a) Press ESC
 - or -
(4b) Click the exitFullscreen link

For (4a), we should fully exit fullscreen and restore the original page.  The browser correctly exits fullscreen mode for the tab, but leaves the iframe element fullscreened.  I.e., only the iframe contents is visible and the top page contents is hidden.

For (4b), it seems that we should exit fullscreen for the DIV and leave the iframe element fullscreened, with the tab still in fullscreen mode.  Currently, the tab exits fullscreen mode, again leaving the iframe element fullscreened and the main frame's contents hidden.

I've tried this on both Firefox and IE, and they both seem to get this right in both cases.

It seems like there are two different problems here.  For browser-initiated exit (4a), Fullscreen::didExitFullScreenForElement is only called on the last frame that entered fullscreen in FullscreenController (m_fullScreenFrame).  In this case, it's the iframe with the div.  Fullscreen::didExitFullScreenForElement is never called on the top frame, so we don't undo the layout changes previously done to make the iframe element fullscreen.

Second, for JS-initiated exit (4b), somehow the algorithm in exitFullscreen doesn't recognize that there's another element in the ancestor frame that should now become fullscreen.  I guess that's what newTop is supposed to do, but it doesn't seem to work across frames?

I haven't yet looked closely at what the spec says we should do for this case and whether it's correct.  Philip, is this a known problem with nested fullscreen?

 

Comment 1 by foolip@chromium.org, Jul 12 2016

This sounds a bit similar to a problem that I noticed last I worked on fullscreen, but never fixed:
https://codereview.chromium.org/909643002

Probably not related, but at the time I also found this:
https://codereview.chromium.org/899933004

Comment 2 by woxxom@gmail.com, Aug 7 2016

I had to use a hack to work around this bug: postMessage from iframe to the parent window, the latter toggled iframe's fullscreen state in event listener for 'message'.
A related case is where the top-level frame has two elements in its fullscreen element stack, where the top one is a cross-origin iframe. If that iframe's document has one element in its stack and a script within calls document.exitFullscreen(), it's not possible to do what the spec currently asks:
https://fullscreen.spec.whatwg.org/#exit-fullscreen
https://fullscreen.spec.whatwg.org/#collect-documents-to-unfullscreen

It's not possible to know what the fullscreen element stack of the top-level frame looks like synchronously in the exitFullscreen() call, so one is left making assumptions, like assuming that it has 1 entry in order to err on the side of fully exiting fullscreen.

(Needs spec change to really get it right.)

Comment 4 by foolip@chromium.org, Dec 19 2016

Another thing to test which came up in https://codereview.chromium.org/2573773002/diff/1/third_party/WebKit/Source/core/dom/Fullscreen.cpp#newcode620 is an A1-B1-A2-B2 nesting situation when exiting from B2, where nested fullscreen in B1 should prevent us from fully exiting, but I was about to land a bug where it would have exited because B2 was a local root.

alexmos@, is there any chance you could add a test for this in SitePerProcessInteractiveBrowserTest? I'm not familiar with the tests and have been happy just to keep them passing :)
#4: Yes, I agree it's a good idea to have a test for this.  I'll work on it after the holidays.
Project Member

Comment 6 by sheriffbot@chromium.org, Mar 9 2018

Labels: Hotlist-Recharge-Cold
Status: Untriaged (was: Available)
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available. If you change it back, also remove the "Hotlist-Recharge-Cold" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Comment 7 by e...@chromium.org, Mar 16 2018

Labels: -Hotlist-Recharge-Cold
Status: Available (was: Untriaged)

Sign in to add a comment