Add support for entering/exiting HTML fullscreen from OOPIFs.

third_party/WebKit/public/web/WebView.h

Index: third_party/WebKit/public/web/WebView.h
diff --git a/third_party/WebKit/public/web/WebView.h b/third_party/WebKit/public/web/WebView.h
index d25040cf7bcebc4c889663ece89737b0b2990b08..0e119a5c3067f2b69247fd22ce05f081f746b22a 100644
--- a/third_party/WebKit/public/web/WebView.h
+++ b/third_party/WebKit/public/web/WebView.h
@@ -334,6 +334,14 @@ public:
         float topControlsHeight,
         bool topControlsShrinkLayout) = 0;
 
+    // This is called in OOPIF scenarios when an element contained in a remote
+    // <iframe> is about to enter fullscreen.  The provided WebRemoteFrame
+    // identifies the frame containing the fullscreen element, and its frame
+    // owner corresponds to the HTMLFrameOwnerElement to be fullscreened.
+    // Calling this prepares FullscreenController to enter fullscreen for that
+    // frame owner.
+    virtual void willEnterFullScreen(WebRemoteFrame*) = 0;

[dcheng, 2016/05/18 01:04:35]

Out of scope for this patch, but is there any hope of unifying this with
WebWidget::didEnterFullScreen in the future?

[alexmos, 2016/05/18 15:08:33]

It could probably be done, though it might be a bit tricky.  Basically, I think
you're suggesting to just call didEnterFullScreen, optionally passing in this
WebRemoteFrame, and inside its implementation, if a remote frame is passed in,
do the additional work to set up the fullscreen events, etc (which
willEnterFullScreen currently does) before proceeding with actual fullscreen
activation - right?

The tricky part is that didEnterFullScreen is triggered by the resize message,
which would now need to carry a routing ID for the remote fullscreen frame, if
any, which means that browser process will have to maintain some state about
which frame has a fullscreened element, so it can tag its routing ID along on
ViewMsg_Resize, and also this routing ID must be computable from
RenderWidgetHostImpl, which doesn't know about proxies, etc.  I actually started
going that route at one point, but abandoned that approach as it grew too
complex.

[dcheng, 2016/05/19 00:21:34]

I looked around the code at this: it looks like we explicitly call WasResized()
when entering/leaving fullscreen. Instead of using WasResized(), maybe it'd make
sense to have an explicit RWH::EnterFullscreen() / ExitFullscreen() with a
corresponding IPC? And maybe we won't need the fullscreen member on
ResizeMsg_Params then... WDYT?

[alexmos, 2016/05/19 01:08:25]

I wish that were true. But actually, in the common case the resize happens from
the ui layer, deep inside the delegate_->EnterFullscreenMode() call, once the
native widgets are actually resized.  That WasResized() call is just insurance
to make sure the resize message is sent, as it's apparently possible to enter
HTML fullscreen without resizing (I'm guessing tab fullscreen followed by HTML
fullscreen would do this).  I've updated the comment there to reflect this.

Here's the stack for the common case:

#1 0x7f81819e01b1 content::RenderWidgetHostImpl::GetResizeParams()
#2 0x7f81819e0492 content::RenderWidgetHostImpl::WasResized()
#3 0x7f8181a00a5c content::RenderWidgetHostViewAura::InternalSetBounds()
#4 0x7f8181a009e9 content::RenderWidgetHostViewAura::SetSize()
#5 0x7f8181a0560b content::RenderWidgetHostViewAura::OnBoundsChanged()
#6 0x7f817cdccd81 aura::Window::OnWindowBoundsChanged()
#7 0x7f817cddf5fc
_ZN4base8internal15RunnableAdapterIMN4aura6WindowEFvRKN3gfx4RectEEE3RunIPS3_JS7_EEEvOT_DpOT0_
#8 0x7f817cddf51e
_ZN4base8internal12InvokeHelperILb0EvNS0_15RunnableAdapterIMN4aura6WindowEFvRKN3gfx4RectEEEEE8MakeItSoIJPS4_S8_EEEvSB_DpOT_
#9 0x7f817cddf4d8
_ZN4base8internal7InvokerINS_13IndexSequenceIJLm0ELm1EEEENS0_9BindStateINS0_15RunnableAdapterIMN4aura6WindowEFvRKN3gfx4RectEEEEFvPS7_SB_EJNS0_17UnretainedWrapperIS7_EESB_EEENS0_12InvokeHelperILb0EvSE_EEFvvEE3RunEPNS0_13BindStateBaseE
#10 0x7f817cf921ce base::Callback<>::Run()
#11 0x7f817cfb415d ui::Layer::SetBoundsFromAnimation()
#12 0x7f817cfcea8c ui::LayerAnimator::SetBounds()
#13 0x7f817cfb037c ui::Layer::SetBounds()
#14 0x7f817cdc96c0 aura::Window::SetBoundsInternal()
#15 0x7f817cdc966c aura::Window::SetBounds()
#16 0x7f8181a00a45 content::RenderWidgetHostViewAura::InternalSetBounds()
#17 0x7f8181a009e9 content::RenderWidgetHostViewAura::SetSize()
#18 0x7f8181cd8e03 content::WebContentsViewAura::SizeChangedCommon()
#19 0x7f8181cdb051 content::WebContentsViewAura::OnBoundsChanged()
#20 0x7f817cdccd81 aura::Window::OnWindowBoundsChanged()
#21 0x7f817cddf5fc
_ZN4base8internal15RunnableAdapterIMN4aura6WindowEFvRKN3gfx4RectEEE3RunIPS3_JS7_EEEvOT_DpOT0_
#22 0x7f817cddf51e
_ZN4base8internal12InvokeHelperILb0EvNS0_15RunnableAdapterIMN4aura6WindowEFvRKN3gfx4RectEEEEE8MakeItSoIJPS4_S8_EEEvSB_DpOT_
#23 0x7f817cddf4d8
_ZN4base8internal7InvokerINS_13IndexSequenceIJLm0ELm1EEEENS0_9BindStateINS0_15RunnableAdapterIMN4aura6WindowEFvRKN3gfx4RectEEEEFvPS7_SB_EJNS0_17UnretainedWrapperIS7_EESB_EEENS0_12InvokeHelperILb0EvSE_EEFvvEE3RunEPNS0_13BindStateBaseE
#24 0x7f817cf921ce base::Callback<>::Run()
#25 0x7f817cfb415d ui::Layer::SetBoundsFromAnimation()
#26 0x7f817cfcea8c ui::LayerAnimator::SetBounds()
#27 0x7f817cfb037c ui::Layer::SetBounds()
#28 0x7f817cdc96c0 aura::Window::SetBoundsInternal()
#29 0x7f817cdc966c aura::Window::SetBounds()
#30 0x7f817d2b20f3 views::NativeViewHostAura::ShowWidget()
#31 0x7f817d1d886c views::NativeViewHost::Layout()
#32 0x7f817d25f5d2 views::View::BoundsChanged()
#33 0x7f817d25f229 views::View::SetBoundsRect()
#34 0x7f817ce30f2a views::WebView::OnBoundsChanged()
#35 0x7f817d25f56c views::View::BoundsChanged()
#36 0x7f817d25f229 views::View::SetBoundsRect()
#37 0x7f818b1e4a7c ContentsLayoutManager::Layout()
#38 0x7f817d260f50 views::View::Layout()
#39 0x7f817d25f5d2 views::View::BoundsChanged()
#40 0x7f817d25f229 views::View::SetBoundsRect()
#41 0x7f818b1de525 BrowserViewLayout::LayoutContentsContainerView()
#42 0x7f818b1ddaad BrowserViewLayout::Layout()
#43 0x7f817d260f50 views::View::Layout()
#44 0x7f818b1d7917 BrowserView::Layout()
#45 0x7f818b1d30a5 BrowserView::UpdateUIForContents()
#46 0x7f818b1d419b BrowserView::ToolbarSizeChanged()
#47 0x7f818b1d37e7 BrowserView::ProcessFullscreen()
#48 0x7f818b1d350b BrowserView::EnterFullscreen()
#49 0x7f818af15a75 FullscreenController::EnterFullscreenModeInternal()
#50 0x7f818af13f77 FullscreenController::ToggleFullscreenModeInternal()
#51 0x7f818af14650 FullscreenController::EnterFullscreenModeForTab()
#52 0x7f818aed13df Browser::EnterFullscreenModeForTab()
#53 0x7f8181ca6436 content::WebContentsImpl::EnterFullscreenMode()
#54 0x7f81814bfdd2 content::RenderFrameHostImpl::OnToggleFullscreen()

I was planning to do what you suggested originally (decoupling enter fullscreen
from resize), but realized that it probably makes sense to do the widget resize
+ fullscreen restyling in one message, in which case layout can be fixed up all
at once.  It's also desirable to fire fullscreen events as a result of the
fullscreen resize so that event handlers can observe the new width/height
(though that has its own issues).

[dcheng, 2016/05/19 05:29:14]

Hmm. Tricky. It's particularly weird because we call RWH::WasResized() in
WebContentsImpl::ExitFullscreenMode()... and we also call it from
RenderFrameHostImpl::OnToggleFullscreen, right before we call into that delegate
code. Maybe something to cleanup for the future I guess.
I agree it makes sense to keep them together.
Another proposal: is it possible to have WasResized() send a distinct IPC for
the fullscreen change case? On the browser side, it could send a
ResizeMsg_Params + optional routing ID in this new IPC. On the renderer side,
there could be a new OnFullscreen handler that delegates to
RenderWidget::Resize(...) to share the core bits, and then calls
DidToggleFullscreen()? Or are there other reasons that we can't separate them
out like this?

+
     // Auto-Resize -----------------------------------------------------------
 
     // In auto-resize mode, the view is automatically adjusted to fit the html