Revert of Add support for entering/exiting HTML fullscreen from OOPIFs.

Revert of Add support for entering/exiting HTML fullscreen from OOPIFs. (patchset #13 id:240001 of https://codereview.chromium.org/1914643005/ )

Reason for revert:
interactive_ui_tests failures on Mac10.10 and Mac10.11 (https://build.chromium.org/p/chromium.mac/builders/Mac10.11%20Tests/builds/1684)

BUG=614304
Original issue's description:
> Add support for entering/exiting HTML fullscreen from OOPIFs.
>
> Currently, entering HTML fullscreen utilizes a number of ancestor
> frame walks.  This is because entering fullscreen for an element (1)
> alters layout for all its ancestor <iframes> (by applying
> :-webkit-full-screen styles to them, which applies some UA CSS rules),
> (2) fires fullscreenchange in all ancestor documents on <iframe>
> elements along the ancestor chain, and (3) makes
> document.webkitFullscreenElement return the <iframe> element
> containing the fullscreened element in ancestor frames.
>
> Currently, the logic behind this assumes that all ancestor frames are
> local and does nothing when it encounters a remote frame.  This CL
> takes the first step to fix this.
>
> The existing flow for entering HTML fullscreen goes like this:
> 1. JS on the page calls element.webkitRequestFullscreen()
> 2. Fullscreen::requestFullscreen():
>    a. Checks if fullscreen is allowed by ancestors (allowFullscreen)
>    b. Creates fullscreenchange events for |element| and its ancestor
>       <iframes> and saves them in its m_eventQueue.
>    c. Puts |element| on its fullscreen element stack.
> 3. FullscreenController::enterFullScreenForElement(element)
>    a. Saves |element| as provisional fullscreen element.
>    b. Saves some page sizing info (to be restored after fullscreen)
> 4. RenderFrameImpl::enterFullscreen sends a FrameHostMsg_ToggleFullscreen
>    to browser process.
> 5. RenderFrameHostImpl::OnToggleFullscreen() asks the current tab to
>    enter fullscreen.
> 6. After the tab is resized for fullscreen, browser process generates a
>    ViewMsg_Resize to the main frame renderer, with
>    is_fullscreen_granted=1 in ResizeParams.
> 7. RenderWidget::Resize realizes there's a fullscreen change and calls
>    into FullscreenController::didEnterFullScreen().
> 8. FullscreenController::didEnterFullScreen picks up the stored
>    provisional fullscreen element and calls
>    Fullscreen::didEnterFullScreenForElement on it.
> 9. Fullscreen::didEnterFullScreenForElement(element):
>    a. Adjusts layout on |element| for fullscreen
>    b. Sets fullscreen CSS styles on the fullscreen element and all
>       ancestor elements.
>    c. Fires fullscreenchange events from step 2b.
>
> The main changes in this CL are:
>
> - in step 5, before entering fullscreen for tab, we will send an IPC
>   to ancestor OOPIFs so that they do steps 2 and 3 for their
>   respective ancestor <iframe> elements (i.e., set up provisional
>   fullscreen elements and prepare their share of the fullscreenchange
>   events).
> - ViewMsg_Resize will trigger fullscreen in subframe widgets in
>   addition to main frame ones.  When fullscreen is entered,
>   ViewMsg_Resize is sent to all widgets on the page.  WebFrameWidgets
>   now also support picking up the fullscreen change and calling into
>   the page's FullscreenController.
> - blink::Fullscreen and FullscreenController now support entering
>   fullscreen for <iframe> elements which contain out-of-process
>   fullscreen elements.
>
> There are still various issues to be dealt with in followup CLs:
> - further refactoring ancestor walks in Fullscreen::requestFullscreen
>   and exitFullscreen to be compatible with hierarchies with a
>   RemoteFrame between LocalFrames (such as A-B-A).  This is needed to
>   fire all ancestor fullscreenchange events properly in such cases.
> - dealing with nested fullscreen elements.
> - optimizing fullscreen layout in ancestor processes.
> - correcting background color when fullscreening an OOP <iframe>
>   element.
>
> More info in design doc: https://goo.gl/Y5wdqi
>
> BUG=550497
> CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_site_isolation
>
> Committed: https://crrev.com/3cf9343f4602d4ec11717cb6ff56a793c1d5f84b
> Cr-Commit-Position: refs/heads/master@{#395500}

TBR=dcheng@chromium.org,creis@chromium.org,falken@chromium.org,alexmos@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=550497
Committed: https://crrev.com/ac446a2973988dd917c7934b925c4878dc34bd43
Cr-Commit-Position: refs/heads/master@{#395553}

[kolos1, 2016-05-24 09:17:41]

Created Revert of Add support for entering/exiting HTML fullscreen from OOPIFs.

[commit-bot: I haz the power, 2016-05-24 09:17:57]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1997413003/1
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1997413003/1

[commit-bot: I haz the power, 2016-05-24 09:18:42]

Description was changed from

==========
Revert of Add support for entering/exiting HTML fullscreen from OOPIFs.
(patchset #13 id:240001 of https://codereview.chromium.org/1914643005/ )

Reason for revert:
interactive_ui_tests failures on Mac10.10 and Mac10.11
(https://build.chromium.org/p/chromium.mac/builders/Mac10.11%20Tests/builds/1684)

BUG=614304

Original issue's description:
> Add support for entering/exiting HTML fullscreen from OOPIFs.
> 
> Currently, entering HTML fullscreen utilizes a number of ancestor
> frame walks.  This is because entering fullscreen for an element (1)
> alters layout for all its ancestor <iframes> (by applying
> :-webkit-full-screen styles to them, which applies some UA CSS rules),
> (2) fires fullscreenchange in all ancestor documents on <iframe>
> elements along the ancestor chain, and (3) makes
> document.webkitFullscreenElement return the <iframe> element
> containing the fullscreened element in ancestor frames.
> 
> Currently, the logic behind this assumes that all ancestor frames are
> local and does nothing when it encounters a remote frame.  This CL
> takes the first step to fix this.
> 
> The existing flow for entering HTML fullscreen goes like this:
> 1. JS on the page calls element.webkitRequestFullscreen()
> 2. Fullscreen::requestFullscreen():
>    a. Checks if fullscreen is allowed by ancestors (allowFullscreen)
>    b. Creates fullscreenchange events for |element| and its ancestor
>       <iframes> and saves them in its m_eventQueue.
>    c. Puts |element| on its fullscreen element stack.
> 3. FullscreenController::enterFullScreenForElement(element)
>    a. Saves |element| as provisional fullscreen element.
>    b. Saves some page sizing info (to be restored after fullscreen)
> 4. RenderFrameImpl::enterFullscreen sends a FrameHostMsg_ToggleFullscreen
>    to browser process.
> 5. RenderFrameHostImpl::OnToggleFullscreen() asks the current tab to
>    enter fullscreen.
> 6. After the tab is resized for fullscreen, browser process generates a
>    ViewMsg_Resize to the main frame renderer, with
>    is_fullscreen_granted=1 in ResizeParams.
> 7. RenderWidget::Resize realizes there's a fullscreen change and calls
>    into FullscreenController::didEnterFullScreen().
> 8. FullscreenController::didEnterFullScreen picks up the stored
>    provisional fullscreen element and calls
>    Fullscreen::didEnterFullScreenForElement on it.
> 9. Fullscreen::didEnterFullScreenForElement(element):
>    a. Adjusts layout on |element| for fullscreen
>    b. Sets fullscreen CSS styles on the fullscreen element and all
>       ancestor elements.
>    c. Fires fullscreenchange events from step 2b.
> 
> The main changes in this CL are:
> 
> - in step 5, before entering fullscreen for tab, we will send an IPC
>   to ancestor OOPIFs so that they do steps 2 and 3 for their
>   respective ancestor <iframe> elements (i.e., set up provisional
>   fullscreen elements and prepare their share of the fullscreenchange
>   events).
> - ViewMsg_Resize will trigger fullscreen in subframe widgets in
>   addition to main frame ones.  When fullscreen is entered,
>   ViewMsg_Resize is sent to all widgets on the page.  WebFrameWidgets
>   now also support picking up the fullscreen change and calling into
>   the page's FullscreenController.
> - blink::Fullscreen and FullscreenController now support entering
>   fullscreen for <iframe> elements which contain out-of-process
>   fullscreen elements.
> 
> There are still various issues to be dealt with in followup CLs:
> - further refactoring ancestor walks in Fullscreen::requestFullscreen
>   and exitFullscreen to be compatible with hierarchies with a
>   RemoteFrame between LocalFrames (such as A-B-A).  This is needed to
>   fire all ancestor fullscreenchange events properly in such cases.
> - dealing with nested fullscreen elements.
> - optimizing fullscreen layout in ancestor processes.
> - correcting background color when fullscreening an OOP <iframe>
>   element.
> 
> More info in design doc: https://goo.gl/Y5wdqi
> 
> BUG=550497
> CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_site_isolation
> 
> Committed: https://crrev.com/3cf9343f4602d4ec11717cb6ff56a793c1d5f84b
> Cr-Commit-Position: refs/heads/master@{#395500}

TBR=dcheng@chromium.org,creis@chromium.org,falken@chromium.org,alexmos@chromi...
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=550497
==========

to

==========
Revert of Add support for entering/exiting HTML fullscreen from OOPIFs.
(patchset #13 id:240001 of https://codereview.chromium.org/1914643005/ )

Reason for revert:
interactive_ui_tests failures on Mac10.10 and Mac10.11
(https://build.chromium.org/p/chromium.mac/builders/Mac10.11%20Tests/builds/1684)

BUG=614304

Original issue's description:
> Add support for entering/exiting HTML fullscreen from OOPIFs.
> 
> Currently, entering HTML fullscreen utilizes a number of ancestor
> frame walks.  This is because entering fullscreen for an element (1)
> alters layout for all its ancestor <iframes> (by applying
> :-webkit-full-screen styles to them, which applies some UA CSS rules),
> (2) fires fullscreenchange in all ancestor documents on <iframe>
> elements along the ancestor chain, and (3) makes
> document.webkitFullscreenElement return the <iframe> element
> containing the fullscreened element in ancestor frames.
> 
> Currently, the logic behind this assumes that all ancestor frames are
> local and does nothing when it encounters a remote frame.  This CL
> takes the first step to fix this.
> 
> The existing flow for entering HTML fullscreen goes like this:
> 1. JS on the page calls element.webkitRequestFullscreen()
> 2. Fullscreen::requestFullscreen():
>    a. Checks if fullscreen is allowed by ancestors (allowFullscreen)
>    b. Creates fullscreenchange events for |element| and its ancestor
>       <iframes> and saves them in its m_eventQueue.
>    c. Puts |element| on its fullscreen element stack.
> 3. FullscreenController::enterFullScreenForElement(element)
>    a. Saves |element| as provisional fullscreen element.
>    b. Saves some page sizing info (to be restored after fullscreen)
> 4. RenderFrameImpl::enterFullscreen sends a FrameHostMsg_ToggleFullscreen
>    to browser process.
> 5. RenderFrameHostImpl::OnToggleFullscreen() asks the current tab to
>    enter fullscreen.
> 6. After the tab is resized for fullscreen, browser process generates a
>    ViewMsg_Resize to the main frame renderer, with
>    is_fullscreen_granted=1 in ResizeParams.
> 7. RenderWidget::Resize realizes there's a fullscreen change and calls
>    into FullscreenController::didEnterFullScreen().
> 8. FullscreenController::didEnterFullScreen picks up the stored
>    provisional fullscreen element and calls
>    Fullscreen::didEnterFullScreenForElement on it.
> 9. Fullscreen::didEnterFullScreenForElement(element):
>    a. Adjusts layout on |element| for fullscreen
>    b. Sets fullscreen CSS styles on the fullscreen element and all
>       ancestor elements.
>    c. Fires fullscreenchange events from step 2b.
> 
> The main changes in this CL are:
> 
> - in step 5, before entering fullscreen for tab, we will send an IPC
>   to ancestor OOPIFs so that they do steps 2 and 3 for their
>   respective ancestor <iframe> elements (i.e., set up provisional
>   fullscreen elements and prepare their share of the fullscreenchange
>   events).
> - ViewMsg_Resize will trigger fullscreen in subframe widgets in
>   addition to main frame ones.  When fullscreen is entered,
>   ViewMsg_Resize is sent to all widgets on the page.  WebFrameWidgets
>   now also support picking up the fullscreen change and calling into
>   the page's FullscreenController.
> - blink::Fullscreen and FullscreenController now support entering
>   fullscreen for <iframe> elements which contain out-of-process
>   fullscreen elements.
> 
> There are still various issues to be dealt with in followup CLs:
> - further refactoring ancestor walks in Fullscreen::requestFullscreen
>   and exitFullscreen to be compatible with hierarchies with a
>   RemoteFrame between LocalFrames (such as A-B-A).  This is needed to
>   fire all ancestor fullscreenchange events properly in such cases.
> - dealing with nested fullscreen elements.
> - optimizing fullscreen layout in ancestor processes.
> - correcting background color when fullscreening an OOP <iframe>
>   element.
> 
> More info in design doc: https://goo.gl/Y5wdqi
> 
> BUG=550497
> CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_site_isolation
> 
> Committed: https://crrev.com/3cf9343f4602d4ec11717cb6ff56a793c1d5f84b
> Cr-Commit-Position: refs/heads/master@{#395500}

TBR=dcheng@chromium.org,creis@chromium.org,falken@chromium.org,alexmos@chromi...
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=550497
==========

[commit-bot: I haz the power, 2016-05-24 09:18:43]

Committed patchset #1 (id:1)

[commit-bot: I haz the power, 2016-05-24 09:20:32]

Description was changed from

==========
Revert of Add support for entering/exiting HTML fullscreen from OOPIFs.
(patchset #13 id:240001 of https://codereview.chromium.org/1914643005/ )

Reason for revert:
interactive_ui_tests failures on Mac10.10 and Mac10.11
(https://build.chromium.org/p/chromium.mac/builders/Mac10.11%20Tests/builds/1684)

BUG=614304

Original issue's description:
> Add support for entering/exiting HTML fullscreen from OOPIFs.
> 
> Currently, entering HTML fullscreen utilizes a number of ancestor
> frame walks.  This is because entering fullscreen for an element (1)
> alters layout for all its ancestor <iframes> (by applying
> :-webkit-full-screen styles to them, which applies some UA CSS rules),
> (2) fires fullscreenchange in all ancestor documents on <iframe>
> elements along the ancestor chain, and (3) makes
> document.webkitFullscreenElement return the <iframe> element
> containing the fullscreened element in ancestor frames.
> 
> Currently, the logic behind this assumes that all ancestor frames are
> local and does nothing when it encounters a remote frame.  This CL
> takes the first step to fix this.
> 
> The existing flow for entering HTML fullscreen goes like this:
> 1. JS on the page calls element.webkitRequestFullscreen()
> 2. Fullscreen::requestFullscreen():
>    a. Checks if fullscreen is allowed by ancestors (allowFullscreen)
>    b. Creates fullscreenchange events for |element| and its ancestor
>       <iframes> and saves them in its m_eventQueue.
>    c. Puts |element| on its fullscreen element stack.
> 3. FullscreenController::enterFullScreenForElement(element)
>    a. Saves |element| as provisional fullscreen element.
>    b. Saves some page sizing info (to be restored after fullscreen)
> 4. RenderFrameImpl::enterFullscreen sends a FrameHostMsg_ToggleFullscreen
>    to browser process.
> 5. RenderFrameHostImpl::OnToggleFullscreen() asks the current tab to
>    enter fullscreen.
> 6. After the tab is resized for fullscreen, browser process generates a
>    ViewMsg_Resize to the main frame renderer, with
>    is_fullscreen_granted=1 in ResizeParams.
> 7. RenderWidget::Resize realizes there's a fullscreen change and calls
>    into FullscreenController::didEnterFullScreen().
> 8. FullscreenController::didEnterFullScreen picks up the stored
>    provisional fullscreen element and calls
>    Fullscreen::didEnterFullScreenForElement on it.
> 9. Fullscreen::didEnterFullScreenForElement(element):
>    a. Adjusts layout on |element| for fullscreen
>    b. Sets fullscreen CSS styles on the fullscreen element and all
>       ancestor elements.
>    c. Fires fullscreenchange events from step 2b.
> 
> The main changes in this CL are:
> 
> - in step 5, before entering fullscreen for tab, we will send an IPC
>   to ancestor OOPIFs so that they do steps 2 and 3 for their
>   respective ancestor <iframe> elements (i.e., set up provisional
>   fullscreen elements and prepare their share of the fullscreenchange
>   events).
> - ViewMsg_Resize will trigger fullscreen in subframe widgets in
>   addition to main frame ones.  When fullscreen is entered,
>   ViewMsg_Resize is sent to all widgets on the page.  WebFrameWidgets
>   now also support picking up the fullscreen change and calling into
>   the page's FullscreenController.
> - blink::Fullscreen and FullscreenController now support entering
>   fullscreen for <iframe> elements which contain out-of-process
>   fullscreen elements.
> 
> There are still various issues to be dealt with in followup CLs:
> - further refactoring ancestor walks in Fullscreen::requestFullscreen
>   and exitFullscreen to be compatible with hierarchies with a
>   RemoteFrame between LocalFrames (such as A-B-A).  This is needed to
>   fire all ancestor fullscreenchange events properly in such cases.
> - dealing with nested fullscreen elements.
> - optimizing fullscreen layout in ancestor processes.
> - correcting background color when fullscreening an OOP <iframe>
>   element.
> 
> More info in design doc: https://goo.gl/Y5wdqi
> 
> BUG=550497
> CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_site_isolation
> 
> Committed: https://crrev.com/3cf9343f4602d4ec11717cb6ff56a793c1d5f84b
> Cr-Commit-Position: refs/heads/master@{#395500}

TBR=dcheng@chromium.org,creis@chromium.org,falken@chromium.org,alexmos@chromi...
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=550497
==========

to

==========
Revert of Add support for entering/exiting HTML fullscreen from OOPIFs.
(patchset #13 id:240001 of https://codereview.chromium.org/1914643005/ )

Reason for revert:
interactive_ui_tests failures on Mac10.10 and Mac10.11
(https://build.chromium.org/p/chromium.mac/builders/Mac10.11%20Tests/builds/1684)

BUG=614304

Original issue's description:
> Add support for entering/exiting HTML fullscreen from OOPIFs.
>
> Currently, entering HTML fullscreen utilizes a number of ancestor
> frame walks.  This is because entering fullscreen for an element (1)
> alters layout for all its ancestor <iframes> (by applying
> :-webkit-full-screen styles to them, which applies some UA CSS rules),
> (2) fires fullscreenchange in all ancestor documents on <iframe>
> elements along the ancestor chain, and (3) makes
> document.webkitFullscreenElement return the <iframe> element
> containing the fullscreened element in ancestor frames.
>
> Currently, the logic behind this assumes that all ancestor frames are
> local and does nothing when it encounters a remote frame.  This CL
> takes the first step to fix this.
>
> The existing flow for entering HTML fullscreen goes like this:
> 1. JS on the page calls element.webkitRequestFullscreen()
> 2. Fullscreen::requestFullscreen():
>    a. Checks if fullscreen is allowed by ancestors (allowFullscreen)
>    b. Creates fullscreenchange events for |element| and its ancestor
>       <iframes> and saves them in its m_eventQueue.
>    c. Puts |element| on its fullscreen element stack.
> 3. FullscreenController::enterFullScreenForElement(element)
>    a. Saves |element| as provisional fullscreen element.
>    b. Saves some page sizing info (to be restored after fullscreen)
> 4. RenderFrameImpl::enterFullscreen sends a FrameHostMsg_ToggleFullscreen
>    to browser process.
> 5. RenderFrameHostImpl::OnToggleFullscreen() asks the current tab to
>    enter fullscreen.
> 6. After the tab is resized for fullscreen, browser process generates a
>    ViewMsg_Resize to the main frame renderer, with
>    is_fullscreen_granted=1 in ResizeParams.
> 7. RenderWidget::Resize realizes there's a fullscreen change and calls
>    into FullscreenController::didEnterFullScreen().
> 8. FullscreenController::didEnterFullScreen picks up the stored
>    provisional fullscreen element and calls
>    Fullscreen::didEnterFullScreenForElement on it.
> 9. Fullscreen::didEnterFullScreenForElement(element):
>    a. Adjusts layout on |element| for fullscreen
>    b. Sets fullscreen CSS styles on the fullscreen element and all
>       ancestor elements.
>    c. Fires fullscreenchange events from step 2b.
>
> The main changes in this CL are:
>
> - in step 5, before entering fullscreen for tab, we will send an IPC
>   to ancestor OOPIFs so that they do steps 2 and 3 for their
>   respective ancestor <iframe> elements (i.e., set up provisional
>   fullscreen elements and prepare their share of the fullscreenchange
>   events).
> - ViewMsg_Resize will trigger fullscreen in subframe widgets in
>   addition to main frame ones.  When fullscreen is entered,
>   ViewMsg_Resize is sent to all widgets on the page.  WebFrameWidgets
>   now also support picking up the fullscreen change and calling into
>   the page's FullscreenController.
> - blink::Fullscreen and FullscreenController now support entering
>   fullscreen for <iframe> elements which contain out-of-process
>   fullscreen elements.
>
> There are still various issues to be dealt with in followup CLs:
> - further refactoring ancestor walks in Fullscreen::requestFullscreen
>   and exitFullscreen to be compatible with hierarchies with a
>   RemoteFrame between LocalFrames (such as A-B-A).  This is needed to
>   fire all ancestor fullscreenchange events properly in such cases.
> - dealing with nested fullscreen elements.
> - optimizing fullscreen layout in ancestor processes.
> - correcting background color when fullscreening an OOP <iframe>
>   element.
>
> More info in design doc: https://goo.gl/Y5wdqi
>
> BUG=550497
> CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_site_isolation
>
> Committed: https://crrev.com/3cf9343f4602d4ec11717cb6ff56a793c1d5f84b
> Cr-Commit-Position: refs/heads/master@{#395500}

TBR=dcheng@chromium.org,creis@chromium.org,falken@chromium.org,alexmos@chromi...
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=550497

Committed: https://crrev.com/ac446a2973988dd917c7934b925c4878dc34bd43
Cr-Commit-Position: refs/heads/master@{#395553}
==========

[commit-bot: I haz the power, 2016-05-24 09:20:33]

Patchset 1 (id:??) landed as
https://crrev.com/ac446a2973988dd917c7934b925c4878dc34bd43
Cr-Commit-Position: refs/heads/master@{#395553}