Move willEnterFullscreen to WebRemoteFrame.

third_party/WebKit/Source/core/dom/Fullscreen.h

Index: third_party/WebKit/Source/core/dom/Fullscreen.h
diff --git a/third_party/WebKit/Source/core/dom/Fullscreen.h b/third_party/WebKit/Source/core/dom/Fullscreen.h
index 9761c4fea2205bd6afc79f296517ba7a32934f89..11ca9584607481d934564165d41abebcebf10db2 100644
--- a/third_party/WebKit/Source/core/dom/Fullscreen.h
+++ b/third_party/WebKit/Source/core/dom/Fullscreen.h
@@ -67,7 +67,10 @@ public:
         PrefixedRequest,
     };
 
-    void requestFullscreen(Element&, RequestType);
+    // |forCrossProcessAncestor| is used in OOPIF scenarios and is set to true
+    // when fullscreen is requested for an out-of-process descendant element.
+    void requestFullscreen(Element&, RequestType, bool forCrossProcessAncestor = false);
+
     static void fullyExitFullscreen(Document&);
     void exitFullscreen();
 
@@ -80,8 +83,8 @@ public:
     // for its (local) iframe container and make sure to also set the
     // ContainsFullScreenElement flag on it (so that it gains the
     // -webkit-full-screen-ancestor style).
-    void didEnterFullScreenForElement(Element*, bool isAncestorOfFullscreenElement);
-    void didExitFullScreenForElement(bool isAncestorOfFullscreenElement);
+    void didEnterFullScreenForElement(Element*);
+    void didExitFullScreenForElement();
 
     void setFullScreenLayoutObject(LayoutFullScreen*);
     LayoutFullScreen* fullScreenLayoutObject() const { return m_fullScreenLayoutObject; }
@@ -89,6 +92,10 @@ public:
 
     void elementRemoved(Element&);
 
+    // Returns true if the current fullscreen element stack corresponds to a
+    // container for an actual fullscreen element in an out-of-process iframe.
+    bool forCrossProcessAncestor() { return m_forCrossProcessAncestor; }
+
     // Mozilla API
     Element* webkitCurrentFullScreenElement() const { return m_fullScreenElement.get(); }
 
@@ -119,6 +126,7 @@ private:
     HeapDeque<Member<Event>> m_eventQueue;
     LayoutRect m_savedPlaceholderFrameRect;
     RefPtr<ComputedStyle> m_savedPlaceholderComputedStyle;
+    bool m_forCrossProcessAncestor;

[alexmos, 2016/05/27 21:14:29]

I thought about whether we need to maintain this on the fullscreen element stack
for nested fullscreen, but actually I don't think that will be necessary:  if
this flag is true and we've entered fullscreen for an element in an OOPIF, that
means nothing in this frame is visible, which means that you can't really enter
fullscreen for a different element in this frame, since there's no way to obtain
a user gesture.

[dcheng, 2016/05/28 19:59:10]

How does this interact with multimonitor though?

[alexmos, 2016/05/31 16:56:25]

I don't think that affects it.  As part of HTML fullscreen, the whole
WebContents goes fullscreen on a particular monitor.  I don't see how to get
into a situation with some element on the page being fullscreen and something
else on the page still visible on a different monitor.

[dcheng, 2016/05/31 17:50:23]

What if you fullcsreen on your secondary monitor and then move the original
browser window to your primary monitor? Do we kick you out of fullscreen if you
try to interact with the browser window that's currently in fullscreen? What if
the browser window spans multiple monitors? Which monitor does it pick?

[alexmos, 2016/05/31 18:08:17]

You can't drag the browser window onto the primary monitor, since none of its
controls are visible in fullscreen.  You might be able to do it via the window
manager -- I tried this in Unity on Linux in workspace switcher mode, and that
allowed me to drag the fullscreened window to the primary monitor or even
position it in between (looks really weird, and is probably a bug in existing
fullscreen code).  That doesn't kick you out of fullscreen, but also doesn't
make anything else visible (the window rect is the same), and focusing back to
fullscreened window resizes it to fill one of the monitors.
On Linux, it seems to pick the monitor which has more of the window area
visible.  Mac didn't seem to allow me to have a window spanning multiple
monitors, snapping to one or the other when you tried to position the window in
between.  I haven't tried Windows but I'd imagine it'd match Linux.

[dcheng, 2016/05/31 18:50:18]

What happens if we fix https://crbug.com/161068 so user gestures follow
postMessage, even across processes?

(It's not clear to me that this bug will ever be fixed for cross process cases,
but it's also not clear to me that this will always be a safe assumption to make
in fullscreen code)

[alexmos, 2016/05/31 23:35:18]

Hmm, that's a really good point, I didn't realize that user gestures can follow
postMessage.  If that bug gets fixed for the cross-process case, then yeah, you
could click on something on the fullscreened child frame, which triggers a
postMessage to parent, which fullscreens a different element.

OK, so then the question is whether or not to wait for cross-process fix for
161068 to do this.  (I don't know how I'd write a realistic test without it.) 
Regardless, for the purposes of this CL, would it be ok to add a TODO here and
mention 161068?  Making this part of the FS element stack will involve a bunch
more plumbing changes, which I don't want to conflate with other changes here.

[dcheng, 2016/06/01 00:29:36]

sgtm. we might want to make a note on the fullscreen bug too: we believe that
this is currently impossible, but who knows what other weird edge cases are out
there...

[alexmos, 2016/06/01 16:50:13]

Done.  I'll add a note to the bug when this lands.

 };
 
 inline bool Fullscreen::isActiveFullScreenElement(const Element& element)