Support disowning window.opener across processes.

Support disowning window.opener across processes.

If a page sets window.opener to null, we need to ensure that all RenderViews
for that window (in any process) also disown their opener.

Also see description in spec:
http://dev.w3.org/html5/spec/single-page.html#disowned-its-opener

Note that this depends on a WebKit change to add didDisownOpener:
https://bugs.webkit.org/show_bug.cgi?id=103789

BUG=156669
TEST=Check window.opener after setting it to null and navigating cross-process.

Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=171384

[Charlie Reis, 2012-12-01 01:46:44]

Nasko, perhaps you could take a first look at this when you get back in town? 
It depends on a WebKit patch, but otherwise it has some similar plumbing to
UpdateFrameTree.  Thanks!

[nasko, 2012-12-03 22:39:02]

Just one question. Great work!

https://codereview.chromium.org/11308301/diff/2002/content/renderer/render_vi...
File content/renderer/render_view_impl.cc (right):

https://codereview.chromium.org/11308301/diff/2002/content/renderer/render_vi...
content/renderer/render_view_impl.cc:2632: DCHECK_EQ(webview()->mainFrame(),
frame);
Is this strong enough guarantee we want to provide such that it warrants CHECK
instead of DCHECK?

[Charlie Reis, 2012-12-03 23:18:30]

https://codereview.chromium.org/11308301/diff/2002/content/renderer/render_vi...
File content/renderer/render_view_impl.cc (right):

https://codereview.chromium.org/11308301/diff/2002/content/renderer/render_vi...
content/renderer/render_view_impl.cc:2632: DCHECK_EQ(webview()->mainFrame(),
frame);
On 2012/12/03 22:39:02, nasko wrote:
> Is this strong enough guarantee we want to provide such that it warrants CHECK
> instead of DCHECK?

Sure, that's a good idea.  We wouldn't want to clear the wrong opener in other
processes if that assumption proves wrong in the wild.  Watching for renderer
crash reports is safer.

[nasko, 2012-12-04 19:16:14]

lgtm

[Charlie Reis, 2012-12-04 21:43:53]

Darin, since you and I had discussed this, I'd like to get your approval as
well.  I'm sticking with the "opener stays valid after a browser-initiated
navigation" approach for the time being.  (I put some thought into it, and we
can discuss further tomorrow.)

I'd like to land it once my WebKit patch
(http://trac.webkit.org/changeset/136516) is rolled into DEPS.  Can you take a
look?

[darin (slow to review), 2012-12-05 06:06:59]

I'm quite nervous about raciness of keeping opener synchronized between
processes.  I can't think of a concrete problem, but that doesn't mean there
isn't one or won't be one in the future :-/

That said, LGTM

https://codereview.chromium.org/11308301/diff/14/content/renderer/render_view...
File content/renderer/render_view_impl.cc (right):

https://codereview.chromium.org/11308301/diff/14/content/renderer/render_view...
content/renderer/render_view_impl.cc:2633: CHECK_EQ(webview()->mainFrame(),
frame);
nit: slightly more compact check would be CHECK(!frame->parent())

https://codereview.chromium.org/11308301/diff/14/content/renderer/render_view...
content/renderer/render_view_impl.cc:6383: if (webview() &&
webview()->mainFrame() && webview()->mainFrame()->opener())
nit: since webview()->mainFrame() is virtual, it might be nice to save on
generated code by caching the result.

[darin (slow to review), 2012-12-05 06:06:59]

I'm quite nervous about raciness of keeping opener synchronized between
processes.  I can't think of a concrete problem, but that doesn't mean there
isn't one or won't be one in the future :-/

That said, LGTM

[darin (slow to review), 2012-12-05 06:07:00]

I'm quite nervous about raciness of keeping opener synchronized between
processes.  I can't think of a concrete problem, but that doesn't mean there
isn't one or won't be one in the future :-/

That said, LGTM

[Charlie Reis, 2012-12-05 19:44:51]

Tom, can you review the two no-argument messages in view_messages.h?

https://codereview.chromium.org/11308301/diff/14/content/renderer/render_view...
File content/renderer/render_view_impl.cc (right):

https://codereview.chromium.org/11308301/diff/14/content/renderer/render_view...
content/renderer/render_view_impl.cc:2633: CHECK_EQ(webview()->mainFrame(),
frame);
On 2012/12/05 06:06:59, darin wrote:
> nit: slightly more compact check would be CHECK(!frame->parent())

Done.

https://codereview.chromium.org/11308301/diff/14/content/renderer/render_view...
content/renderer/render_view_impl.cc:6383: if (webview() &&
webview()->mainFrame() && webview()->mainFrame()->opener())
On 2012/12/05 06:06:59, darin wrote:
> nit: since webview()->mainFrame() is virtual, it might be nice to save on
> generated code by caching the result.

Done.

[Tom Sepez, 2012-12-05 19:49:30]

Messages LGTM.

[commit-bot: I haz the power, 2012-12-05 20:17:33]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/[email protected]/11308301/17001

[commit-bot: I haz the power, 2012-12-06 02:32:28]

Change committed as 171384