Allow createLocalChild to specify previous sibling frame.

Allow createLocalChild to specify previous sibling frame.

This will be used by the content side to ensure that local frames are
inserted into the tree in the correct place.  Previously, we always
appended local frames last, after all remote frames.  This CL will
allow the browser process to pass the previous sibling's routing ID
when sending an IPC message to create a new local frame.

Note that the we can't just create all the local and remote frames in
the right order to start with.  A new renderer's local frame still has
to be created after all the remote frames, so that it won't try to
access a proxy that doesn't exist yet.

Corresponding Chromium CL: https://codereview.chromium.org/1113393004

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

[alexmos, 2015-05-01 22:37:03]

alexmos@chromium.org changed reviewers:
+ dcheng@chromium.org

[alexmos, 2015-05-01 22:37:04]

Daniel, can you please take a look?  This is a prerequisite for fixing the
indexed window access.

[dcheng, 2015-05-01 22:58:53]

Can you update the CL description to explain why we can't just create the frames
in the right order?

[alexmos, 2015-05-01 23:24:26]

On 2015/05/01 22:58:53, dcheng wrote:
> Can you update the CL description to explain why we can't just create the
frames
> in the right order?

Sure, you mean that we don't want a local frame to try accessing a proxy that
hasn't been created yet?  Added that to the description.

[dcheng, 2015-05-01 23:39:36]

https://codereview.chromium.org/1119823003/diff/20001/Source/web/WebFrame.cpp
File Source/web/WebFrame.cpp (right):

https://codereview.chromium.org/1119823003/diff/20001/Source/web/WebFrame.cpp...
Source/web/WebFrame.cpp:173: {
Should we re-express this in terms of insertAfter()?

[alexmos, 2015-05-02 00:21:45]

https://codereview.chromium.org/1119823003/diff/20001/Source/web/WebFrame.cpp
File Source/web/WebFrame.cpp (right):

https://codereview.chromium.org/1119823003/diff/20001/Source/web/WebFrame.cpp...
Source/web/WebFrame.cpp:173: {
On 2015/05/01 23:39:36, dcheng wrote:
> Should we re-express this in terms of insertAfter()?

Done.  Thanks for reminding me to do it!  Any thoughts on what to do  with the
FIXME?  I don't know the context, so I've kept it for now.

[dcheng, 2015-05-04 17:30:36]

lgtm

https://codereview.chromium.org/1119823003/diff/20001/Source/web/WebFrame.cpp
File Source/web/WebFrame.cpp (right):

https://codereview.chromium.org/1119823003/diff/20001/Source/web/WebFrame.cpp...
Source/web/WebFrame.cpp:173: {
On 2015/05/02 at 00:21:45, alexmos wrote:
> On 2015/05/01 23:39:36, dcheng wrote:
> > Should we re-express this in terms of insertAfter()?
> 
> Done.  Thanks for reminding me to do it!  Any thoughts on what to do  with the
FIXME?  I don't know the context, so I've kept it for now.


The original check was to make sure we didn't accidentally appendChild a frame
that belonged to another page. I guess we could ASSERT that the value of
WebFrame::view() is the same.

https://codereview.chromium.org/1119823003/diff/40001/Source/web/tests/WebFra...
File Source/web/tests/WebFrameTest.cpp (right):

https://codereview.chromium.org/1119823003/diff/40001/Source/web/tests/WebFra...
Source/web/tests/WebFrameTest.cpp:7340: EXPECT_EQ(parent,
fourthFrame->parent());
I wonder if some version of nick's frame tree printer would be useful here.

[alexmos, 2015-05-04 21:38:54]

Thanks!

https://codereview.chromium.org/1119823003/diff/20001/Source/web/WebFrame.cpp
File Source/web/WebFrame.cpp (right):

https://codereview.chromium.org/1119823003/diff/20001/Source/web/WebFrame.cpp...
Source/web/WebFrame.cpp:173: {
On 2015/05/04 17:30:36, dcheng wrote:
> On 2015/05/02 at 00:21:45, alexmos wrote:
> > On 2015/05/01 23:39:36, dcheng wrote:
> > > Should we re-express this in terms of insertAfter()?
> > 
> > Done.  Thanks for reminding me to do it!  Any thoughts on what to do  with
the
> FIXME?  I don't know the context, so I've kept it for now.
> 
> 
> The original check was to make sure we didn't accidentally appendChild a frame
> that belonged to another page. I guess we could ASSERT that the value of
> WebFrame::view() is the same.

Hmm, that doesn't seem to work, because we call insertAfter() before we
initialize the new child's core frame, so the new child's view() is null.  I'll
leave the assert as-is for now.

https://codereview.chromium.org/1119823003/diff/40001/Source/web/tests/WebFra...
File Source/web/tests/WebFrameTest.cpp (right):

https://codereview.chromium.org/1119823003/diff/40001/Source/web/tests/WebFra...
Source/web/tests/WebFrameTest.cpp:7340: EXPECT_EQ(parent,
fourthFrame->parent());
On 2015/05/04 17:30:36, dcheng wrote:
> I wonder if some version of nick's frame tree printer would be useful here.

Yeah, that would be very handy. :)  Would probably also simplify consistency
checks for the swap tests.  I'll see if I can get to it some day.

[alexmos, 2015-05-04 23:32:13]

The CQ bit was checked by alexmos@chromium.org

[commit-bot: I haz the power, 2015-05-04 23:32:27]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1119823003/40001

[commit-bot: I haz the power, 2015-05-05 01:45:23]

Committed patchset #3 (id:40001) as
https://src.chromium.org/viewvc/blink?view=rev&revision=194897