Move DisownOpener to RenderFrameHost / RenderFrameProxyHost.

Move DisownOpener to RenderFrameHost / RenderFrameProxyHost.

BUG=304341
TEST=RenderFrameHostManagerTest.Disown*

Committed: https://crrev.com/bbbeb06ad9b5f49e04ebdacd61a3c4466ee5b87d
Cr-Commit-Position: refs/heads/master@{#291717}

[Charlie Reis, 2014-08-22 20:46:28]

Nasko: Here's the rest of the changes to move DisownOpener to RenderFrameHost.

Technically, the DisownOpener message usually goes to RenderFrameProxies, but we
need to be able to send it to RenderFrames as well (in the recent cross-process
navigation case from the last CL).

Apologies that this CL appears to also include all my changes from
https://codereview.chromium.org/497183003/.  I must have done something wrong
when uploading from that git branch.  I'll rebase once the first CL lands so
that this has just the RVH->RFH stuff.

[nasko, 2014-08-25 15:47:14]

Just a couple of things. Also, let's use this CL to fix a nit from
https://codereview.chromium.org/497183003/.

https://codereview.chromium.org/505443002/diff/1/content/renderer/render_fram...
File content/renderer/render_frame_impl.cc (right):

https://codereview.chromium.org/505443002/diff/1/content/renderer/render_fram...
content/renderer/render_frame_impl.cc:783:
IPC_MESSAGE_HANDLER(FrameMsg_DisownOpener, OnDisownOpener)
nit: Don't put IPC handlers after the #ifdef'd ones.

https://codereview.chromium.org/505443002/diff/1/content/renderer/render_fram...
content/renderer/render_frame_impl.cc:1166: if (frame_->opener())
Should we restrict this to main frames only? I'm not sure we have a clear
picture of what it means for a subframe to have an opener, so preserving
existing behavior might be desirable.
On the other hand, disowning an opener is "safer" operation since it will
disable operations, rather than enable, so I'm not quite sure which way is
better.

[Charlie Reis, 2014-08-25 17:10:24]

Thanks!  Fixes uploaded.  (Caveat: I'm still updating my local build after the
git migration, so I'm relying on the try jobs at the moment to make sure it
works.  I'll check manually before committing.)

I've removed the unused URL from the extra test as well.

https://codereview.chromium.org/505443002/diff/1/content/renderer/render_fram...
File content/renderer/render_frame_impl.cc (right):

https://codereview.chromium.org/505443002/diff/1/content/renderer/render_fram...
content/renderer/render_frame_impl.cc:783:
IPC_MESSAGE_HANDLER(FrameMsg_DisownOpener, OnDisownOpener)
On 2014/08/25 15:47:14, nasko wrote:
> nit: Don't put IPC handlers after the #ifdef'd ones.

Done.

https://codereview.chromium.org/505443002/diff/1/content/renderer/render_fram...
content/renderer/render_frame_impl.cc:1166: if (frame_->opener())
On 2014/08/25 15:47:14, nasko wrote:
> Should we restrict this to main frames only? I'm not sure we have a clear
> picture of what it means for a subframe to have an opener, so preserving
> existing behavior might be desirable.
> On the other hand, disowning an opener is "safer" operation since it will
> disable operations, rather than enable, so I'm not quite sure which way is
> better.

I've changed it to have a check and a TODO.  We'll need to move opener_ from
WebContents to FrameTreeNode before it makes sense to clear an opener on a
subframe.

[nasko, 2014-08-25 17:23:46]

LGTM

[Charlie Reis, 2014-08-25 17:46:40]

The CQ bit was checked by creis@chromium.org

[commit-bot: I haz the power, 2014-08-25 17:48:10]

CQ is trying da patch. Follow status at
 https://chromium-status.appspot.com/cq/creis@chromium.org/505443002/60001

[commit-bot: I haz the power, 2014-08-25 18:20:50]

Committed patchset #3 (60001) as e4930be334a7ee213ea25e60ded537b72dd1f176

[commit-bot: I haz the power, 2014-09-10 02:35:47]

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