Framework for converting embedder uses of WebFrame to WebLocalFrame.

Framework for converting embedder uses of WebFrame to WebLocalFrame.

This patch adds a typedef for WebFrame so we can start converting
references to WebFrame in embedder implementations. It also updates most
references of WebFrame in the embedding API to WebLocalFrame instead.
Most locations should only ever have to handle WebLocalFrames, so it's
just a fairly straightforward rename. However, there are some corner
cases that need to be adjusted more carefully, since things like the
opener, parent frame, and child frames can be pointers to an eventual
WebRemoteFrame class.

BUG=346764
Committed: https://src.chromium.org/viewvc/blink?view=rev&revision=169638

[dcheng, 2014-03-08 01:32:22]

First stab at making it possible to start converting Chrome uses of WebFrame.
I've gone ahead and changed most references in the embedding layer as well,
since I expect most of these to only ever work with local frames. There are
several notable exceptions:

WebFrameClient::createChildFrame() -- since this could create a remote frame if
it's cross-site instance, I think it should return a WebFrame.
WebFrameClient::frameDetached() -- I'm uncertain of this one, but I think we
need this so we can forward the detach of a remote frame to the correct process
in the embedder.
WebFrameClient::willCheckAndDispatchMessageEvent() -- the target frame could be
a remote frame.
WebFrame::opener()
WebFrame::setOpener()
WebFrame::parent()
WebFrame::top()
WebFrame::previousSibling()
WebFrame::nextSibling()
WebFrame::firstChild()
WebFrame::lastChild()

We should probably split up WebFrameClient as well (since it looks like the
majority of methods aren't relevant to remote frames), but I think that should
be a separate patch.

[dcheng, 2014-03-10 20:37:26]

On 2014/03/08 01:32:22, dcheng wrote:
> First stab at making it possible to start converting Chrome uses of WebFrame.
> I've gone ahead and changed most references in the embedding layer as well,
> since I expect most of these to only ever work with local frames. There are
> several notable exceptions:
> 
> WebFrameClient::createChildFrame() -- since this could create a remote frame
if
> it's cross-site instance, I think it should return a WebFrame.
> WebFrameClient::frameDetached() -- I'm uncertain of this one, but I think we
> need this so we can forward the detach of a remote frame to the correct
process
> in the embedder.
> WebFrameClient::willCheckAndDispatchMessageEvent() -- the target frame could
be
> a remote frame.
> WebFrame::opener()
> WebFrame::setOpener()
> WebFrame::parent()
> WebFrame::top()
> WebFrame::previousSibling()
> WebFrame::nextSibling()
> WebFrame::firstChild()
> WebFrame::lastChild()
> 
> We should probably split up WebFrameClient as well (since it looks like the
> majority of methods aren't relevant to remote frames), but I think that should
> be a separate patch.

Ping?

[dcheng, 2014-03-19 21:52:37]

-jamesr per his request.

Adam, do you mind taking a look at this CL? This needs to roll into Chrome so I
can start converting Chrome usages of WebFrames so we can properly split
WebFrame and WebLocalFrame apart in Blink.

[abarth-chromium, 2014-03-19 22:42:06]

lgtm

https://codereview.chromium.org/191003006/diff/80001/public/web/WebAutofillCl...
File public/web/WebAutofillClient.h (right):

https://codereview.chromium.org/191003006/diff/80001/public/web/WebAutofillCl...
public/web/WebAutofillClient.h:34: #include "WebFrame.h"
It's too bad that we can't use a forward declaration here.

[dcheng, 2014-03-19 23:05:25]

The CQ bit was checked by dcheng@chromium.org

[commit-bot: I haz the power, 2014-03-19 23:05:33]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/dcheng@chromium.org/191003006/80001

[commit-bot: I haz the power, 2014-03-20 00:26:31]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2014-03-20 00:26:32]

Failed to apply patch for public/web/WebDOMFileSystem.h:
While running patch -p1 --forward --force --no-backup-if-mismatch;
  patching file public/web/WebDOMFileSystem.h
  Hunk #1 FAILED at 35.
  1 out of 3 hunks FAILED -- saving rejects to file
public/web/WebDOMFileSystem.h.rej

Patch:       public/web/WebDOMFileSystem.h
Index: public/web/WebDOMFileSystem.h
diff --git a/public/web/WebDOMFileSystem.h b/public/web/WebDOMFileSystem.h
index
5279cc07c3b5206f6dd338cea6eb510c6352a411..aa32652608777e66bea6f6315d0d5ba414c9952a
100644
--- a/public/web/WebDOMFileSystem.h
+++ b/public/web/WebDOMFileSystem.h
@@ -35,6 +35,7 @@
 #include "../platform/WebPrivatePtr.h"
 #include "../platform/WebString.h"
 #include "../platform/WebURL.h"
+#include "WebFrame.h"
 
 #if BLINK_IMPLEMENTATION
 #include "heap/Handle.h"
@@ -49,8 +50,6 @@ namespace WebCore { class DOMFileSystem; }
 
 namespace blink {
 
-class WebFrame;
-
 class WebDOMFileSystem {
 public:
     enum SerializableType {
@@ -77,7 +76,7 @@ public:
     // FIXME: Deprecate the last argument when all filesystems become
     // serializable.
     BLINK_EXPORT static WebDOMFileSystem create(
-        WebFrame*,
+        WebLocalFrame*,
         WebFileSystemType,
         const WebString& name,
         const WebURL& rootURL,

[dcheng, 2014-03-20 08:51:34]

The CQ bit was checked by dcheng@chromium.org

[commit-bot: I haz the power, 2014-03-20 08:51:40]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/dcheng@chromium.org/191003006/100001

[commit-bot: I haz the power, 2014-03-20 09:54:18]

Change committed as 169638

[viettrungluu, 2014-03-22 07:42:09]

I think this broke the Mac ASan 64 build:

http://build.chromium.org/p/chromium.memory/builders/Mac%20ASan%2064%20Builde...

[viettrungluu, 2014-03-22 07:45:34]

On 2014/03/22 07:42:09, viettrungluu wrote:
> I think this broke the Mac ASan 64 build:
> 
>
http://build.chromium.org/p/chromium.memory/builders/Mac%2520ASan%252064%2520...

Excuse the invalid link; it's rietveld trying to be clever. (Replace the |%25|s
with just |%|s.)

[eseidel, 2014-03-24 01:35:00]

A revert of this CL has been created in
https://codereview.chromium.org/208393012/ by eseidel@chromium.org.

The reason for reverting is: This is believed to break the Mac 64-bit build. 
jar just rolled back the Blink roll in an attempt to fix it.

https://codereview.chromium.org/208393010/.