Handle frame openers in the same FrameTree when navigating subframes.

Handle frame openers in the same FrameTree when navigating subframes.

When a frame navigates to a new SiteInstance,
CreateOpenerProxiesIfNeeded is called to create proxies for the
frame's opener chain in the new SiteInstance.  Currently,
CreateOpenerProxiesIfNeeded simply invokes CreateOpenerProxies on the
frame's opener.  This works correctly for top-level frames, but it
doesn't work for subframes.

For example, suppose a top-level frame A has an opener X and a
subframe that navigates to B.  With today's approach, X won't get a
proxy in process B, since CreateOpenerProxiesIfNeeded only tries to
follow the subframe's opener (which is null).  This is wrong, because
the subframe can access X with window.parent.opener.  Instead, when
CreateOpenerProxiesIfNeeded is called on a subframe, it needs to
follow openers of other nodes of the same FrameTree as well, not just
the current node.  This CL fixes this.

The proxy creation logic when navigating a FTN to a new SiteInstance
does two things:
1. Call CreateOpenerProxiesIfNeeded, which just calls
   CreateOpenerProxies on the current node's opener. (Only done when
   navigating to a related SiteInstance.)
2. Call CreateProxiesForSiteInstance to create proxies for all nodes
   in the current FrameTree, skipping over the node that's navigating.

This CL changes (1) to directly call CreateOpenerProxies, which
already handles openers for all nodes in the same FrameTree.
Additional plumbing is added to ensure we don't try to create proxies
in the node that's being navigated.  Because CreateOpenerProxies
starts from the FrameTree of the current node and not from the tree of
its opener, this means that essentially, (2) is now done as part of
(1) (when the node is navigating to a related SiteInstance).

BUG=225940
Committed: https://crrev.com/90325cfabf9c0932eb13b4ed9ace2e3940540f89
Cr-Commit-Position: refs/heads/master@{#346949}

[alexmos, 2015-08-25 22:38:07]

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

[alexmos, 2015-08-25 22:38:08]

Charlie, what do you think about this general approach?  Although the problem
looks pretty simple, the fix is turning out to be tricky.  On the plus side, I
think we can get rid of CreateOpenerProxiesIfNeeded and just use
CreateOpenerProxies everywhere.  On the down side, it needs the added plumbing
to skip a node, so that it can pass it into CreateProxiesForSiteInstance when
processing the FrameTree of the node that's navigating.  

An alternate way could be to change CreateRenderFrameProxy to just exit instead
of CHECK if it tries to create a proxy in the same SiteInstance as a node's
current RFH, but that doesn't seem good.  I was also thinking of keeping
CreateOpenerProxiesIfNeeded and just doing a ForEach for all nodes, calling
CreateOpenerProxies on each node's opener, but that doesn't solve the problem of
potentially ending up at the navigating node via a complex opener chain and
trying to create a proxy for it.

https://codereview.chromium.org/1309043003/diff/100001/content/browser/frame_...
File content/browser/frame_host/render_frame_host_manager.cc (left):

https://codereview.chromium.org/1309043003/diff/100001/content/browser/frame_...
content/browser/frame_host/render_frame_host_manager.cc:1880:
CreateOpenerProxiesIfNeeded(instance);
I don't think this is actually needed.  EnsureRenderViewInitialized is called in
only two places: CreateOpenerProxiesForFrameTree and
CreateProxiesForSiteInstance.  In the first case, calling this is redundant as
we're already in the middle of creating opener proxies, and in the second case,
it is also redundant because the only way to get to CreateProxiesForSiteInstance
is either while creating opener proxies or right after we've done that in
CreateProxiesForNewRenderFrameHost.

I saw that lazyboy@ introduced this in
https://codereview.chromium.org/782093002, but I didn't see a clear reason in
the comments, and none of the tests are affected by removing this.

https://codereview.chromium.org/1309043003/diff/100001/content/browser/frame_...
content/browser/frame_host/render_frame_host_manager.cc:2539: if (rvh &&
rvh->IsRenderViewLive() && !need_proxy_for_pending_rvh)
I've moved this logic to only be used when not in --site-per-process.  I found
that sometimes this isn't actually a sufficient condition to exit early and
assume all proxies have been created, with an example setup in
RenderFrameHostManagerTest.DetachPendingChild.  Basically, suppose a subframe in
this tree navigates from A to B.  This creates a swapped-out RVH for its tree in
B.  Now, while that subframe is still pending, suppose another frame navigated
to B and we get here trying to create a proxy in B for the first subframe.  We
should create that proxy so that if the second frame commits earlier, it has a
way to talk to the first subframe until that also commits (if ever), but
currently, this early-exits without creating a proxy, since the swapped-out RVH
in B already exists.

Calling CreateProxiesForSiteInstance when the proxies already exist already has
the right early-exits, and I think the RVH checks actually makes more sense this
way, as they're tied to swapped-out RVH creation.

https://codereview.chromium.org/1309043003/diff/100001/content/browser/frame_...
File content/browser/frame_host/render_frame_host_manager.cc (right):

https://codereview.chromium.org/1309043003/diff/100001/content/browser/frame_...
content/browser/frame_host/render_frame_host_manager.cc:2525: if
(SiteIsolationPolicy::AreCrossProcessFramesPossible()) {
I think we've been meaning to change this to AreCrossProcessFramesPossible in
Nick's policy CL, but forgot.  Since CreateProxiesForSiteInstance creates
proxies for subframes, I think this is the right gating function for this, and
this also matches the condition used by the other call site of
CreateProxiesForSiteInstance.

https://codereview.chromium.org/1309043003/diff/100001/content/browser/frame_...
content/browser/frame_host/render_frame_host_manager.cc:2531:
frame_tree->CreateProxiesForSiteInstance(skip_this_node, instance);
We were always passing nullptr here, assuming none of the openers' FrameTrees
will ever be the same as the FrameTree of the node that is being navigated.  

This isn't true anymore, as I'm calling CreateOpenerProxies on the node itself,
rather than its opener, meaning we start right from the node's FrameTree (and we
need to skip the node itself).

I think this was already a problem even without this CL though: with opener
updates, the opener chain could lead us back to the original navigating node's
FrameTree and pass null here, which would crash trying to create a proxy in the
node's own current SiteInstance.

https://codereview.chromium.org/1309043003/diff/100001/content/browser/web_co...
File content/browser/web_contents/web_contents_impl.cc (right):

https://codereview.chromium.org/1309043003/diff/100001/content/browser/web_co...
content/browser/web_contents/web_contents_impl.cc:4152: GetSiteInstance(),
nullptr);
Using nullptr keeps today's behavior, but I'm thinking this actually should use
the target's FTN, because if the opener chain of the source node ever leads us
to the target node, we want to make sure not to try to create a proxy for the
target node in its own SiteInstance (given that I've moved the RVH-based
checks).  If you agree, I can add the plumbing to get the target here.  Or maybe
we shouldn't even call EnsureOpenerProxiesExist if AreCrossProcessFramesPossible
is true (in which case all proxies should've already been created).

[Charlie Reis, 2015-08-31 20:49:44]

This seems reasonable to me.  A few minor comments and replies below.

https://codereview.chromium.org/1309043003/diff/100001/content/browser/frame_...
File content/browser/frame_host/render_frame_host_manager.cc (left):

https://codereview.chromium.org/1309043003/diff/100001/content/browser/frame_...
content/browser/frame_host/render_frame_host_manager.cc:1880:
CreateOpenerProxiesIfNeeded(instance);
On 2015/08/25 22:38:08, alexmos wrote:
> I don't think this is actually needed.  EnsureRenderViewInitialized is called
in
> only two places: CreateOpenerProxiesForFrameTree and
> CreateProxiesForSiteInstance.  In the first case, calling this is redundant as
> we're already in the middle of creating opener proxies, and in the second
case,
> it is also redundant because the only way to get to
CreateProxiesForSiteInstance
> is either while creating opener proxies or right after we've done that in
> CreateProxiesForNewRenderFrameHost.
> 
> I saw that lazyboy@ introduced this in
> https://codereview.chromium.org/782093002, but I didn't see a clear reason in
> the comments, and none of the tests are affected by removing this.

Acknowledged.

https://codereview.chromium.org/1309043003/diff/100001/content/browser/frame_...
content/browser/frame_host/render_frame_host_manager.cc:2539: if (rvh &&
rvh->IsRenderViewLive() && !need_proxy_for_pending_rvh)
On 2015/08/25 22:38:08, alexmos wrote:
> I've moved this logic to only be used when not in --site-per-process.  I found
> that sometimes this isn't actually a sufficient condition to exit early and
> assume all proxies have been created, with an example setup in
> RenderFrameHostManagerTest.DetachPendingChild.  Basically, suppose a subframe
in
> this tree navigates from A to B.  This creates a swapped-out RVH for its tree
in
> B.  Now, while that subframe is still pending, suppose another frame navigated
> to B and we get here trying to create a proxy in B for the first subframe.  We
> should create that proxy so that if the second frame commits earlier, it has a
> way to talk to the first subframe until that also commits (if ever), but
> currently, this early-exits without creating a proxy, since the swapped-out
RVH
> in B already exists.
> 
> Calling CreateProxiesForSiteInstance when the proxies already exist already
has
> the right early-exits, and I think the RVH checks actually makes more sense
this
> way, as they're tied to swapped-out RVH creation.

Acknowledged.

https://codereview.chromium.org/1309043003/diff/100001/content/browser/frame_...
File content/browser/frame_host/render_frame_host_manager.cc (right):

https://codereview.chromium.org/1309043003/diff/100001/content/browser/frame_...
content/browser/frame_host/render_frame_host_manager.cc:417:
CreateOpenerProxies(dest_render_frame_host->GetSiteInstance(),
Looks like we can call this inside subframe RFHMs, right?  That would fail the
DCHECK in CreateOpenerProxiesForFrameTree.

https://codereview.chromium.org/1309043003/diff/100001/content/browser/frame_...
content/browser/frame_host/render_frame_host_manager.cc:1043:
CreateOpenerProxies(navigation_rfh->GetSiteInstance(), frame_tree_node_);
As above, I think this can happen in a subframe and fail the DCHECK below.

https://codereview.chromium.org/1309043003/diff/100001/content/browser/frame_...
content/browser/frame_host/render_frame_host_manager.cc:1582: else if
(SiteIsolationPolicy::AreCrossProcessFramesPossible()) {
Style nit: The earlier if branch needs braces if the else needs braces (now that
they're combined into the same conditional).

https://codereview.chromium.org/1309043003/diff/100001/content/browser/frame_...
content/browser/frame_host/render_frame_host_manager.cc:2520:
DCHECK(frame_tree_node_->IsMainFrame());
This doesn't look like it's true.  There's a few call sites above that look like
they could be made from a subframe RFHM.  Is there a reason you need it to start
from the main frame?

https://codereview.chromium.org/1309043003/diff/100001/content/browser/frame_...
content/browser/frame_host/render_frame_host_manager.cc:2525: if
(SiteIsolationPolicy::AreCrossProcessFramesPossible()) {
On 2015/08/25 22:38:08, alexmos wrote:
> I think we've been meaning to change this to AreCrossProcessFramesPossible in
> Nick's policy CL, but forgot.  Since CreateProxiesForSiteInstance creates
> proxies for subframes, I think this is the right gating function for this, and
> this also matches the condition used by the other call site of
> CreateProxiesForSiteInstance.

Acknowledged.

https://codereview.chromium.org/1309043003/diff/100001/content/browser/frame_...
content/browser/frame_host/render_frame_host_manager.cc:2531:
frame_tree->CreateProxiesForSiteInstance(skip_this_node, instance);
On 2015/08/25 22:38:08, alexmos wrote:
> We were always passing nullptr here, assuming none of the openers' FrameTrees
> will ever be the same as the FrameTree of the node that is being navigated.  
> 
> This isn't true anymore, as I'm calling CreateOpenerProxies on the node
itself,
> rather than its opener, meaning we start right from the node's FrameTree (and
we
> need to skip the node itself).
> 
> I think this was already a problem even without this CL though: with opener
> updates, the opener chain could lead us back to the original navigating node's
> FrameTree and pass null here, which would crash trying to create a proxy in
the
> node's own current SiteInstance.

Acknowledged.

https://codereview.chromium.org/1309043003/diff/100001/content/browser/site_p...
File content/browser/site_per_process_browsertest.cc (right):

https://codereview.chromium.org/1309043003/diff/100001/content/browser/site_p...
content/browser/site_per_process_browsertest.cc:3013:
embedded_test_server()->GetURL("bar.com", "/frame_tree/2-4.html"));
Anything specific about this page, or can we use the cross_site_iframe_factory?

https://codereview.chromium.org/1309043003/diff/100001/content/browser/web_co...
File content/browser/web_contents/web_contents_impl.cc (right):

https://codereview.chromium.org/1309043003/diff/100001/content/browser/web_co...
content/browser/web_contents/web_contents_impl.cc:4152: GetSiteInstance(),
nullptr);
On 2015/08/25 22:38:08, alexmos wrote:
> Using nullptr keeps today's behavior, but I'm thinking this actually should
use
> the target's FTN, because if the opener chain of the source node ever leads us
> to the target node, we want to make sure not to try to create a proxy for the
> target node in its own SiteInstance (given that I've moved the RVH-based
> checks).  If you agree, I can add the plumbing to get the target here.

Interesting.  Is that something we could write a test for?  Sounds worth fixing.

(The downside is that this method's name doesn't sound like it's specific to
postMessage, but in reality I think it is.  The comment in RFHD says it will
even go away once <webview> fixes some postMessage plumbing.  Incidentally, it
also claims the method returns the routing ID, which looks stale.)  :)

>  Or maybe
> we shouldn't even call EnsureOpenerProxiesExist if
AreCrossProcessFramesPossible
> is true (in which case all proxies should've already been created).

That sounds possibly orthogonal.  We could still hit the issue you describe
above with only main frames, right?  Or do the RVH checks in
!AreCrossProcessFramesPossible take care of that?

Given that this method exists for a <webview> special case, then calling it only
when needed might make more sense.

[alexmos, 2015-09-01 22:12:28]

Thanks for reviewing!

https://codereview.chromium.org/1309043003/diff/100001/content/browser/frame_...
File content/browser/frame_host/render_frame_host_manager.cc (right):

https://codereview.chromium.org/1309043003/diff/100001/content/browser/frame_...
content/browser/frame_host/render_frame_host_manager.cc:417:
CreateOpenerProxies(dest_render_frame_host->GetSiteInstance(),
On 2015/08/31 20:49:43, Charlie Reis wrote:
> Looks like we can call this inside subframe RFHMs, right?  That would fail the
> DCHECK in CreateOpenerProxiesForFrameTree.

Please see my response on the DCHECK.

https://codereview.chromium.org/1309043003/diff/100001/content/browser/frame_...
content/browser/frame_host/render_frame_host_manager.cc:1043:
CreateOpenerProxies(navigation_rfh->GetSiteInstance(), frame_tree_node_);
On 2015/08/31 20:49:43, Charlie Reis wrote:
> As above, I think this can happen in a subframe and fail the DCHECK below.

Please see my response on the DCHECK.

https://codereview.chromium.org/1309043003/diff/100001/content/browser/frame_...
content/browser/frame_host/render_frame_host_manager.cc:1582: else if
(SiteIsolationPolicy::AreCrossProcessFramesPossible()) {
On 2015/08/31 20:49:43, Charlie Reis wrote:
> Style nit: The earlier if branch needs braces if the else needs braces (now
that
> they're combined into the same conditional).

Done.

https://codereview.chromium.org/1309043003/diff/100001/content/browser/frame_...
content/browser/frame_host/render_frame_host_manager.cc:2520:
DCHECK(frame_tree_node_->IsMainFrame());
On 2015/08/31 20:49:43, Charlie Reis wrote:
> This doesn't look like it's true.  There's a few call sites above that look
like
> they could be made from a subframe RFHM.  Is there a reason you need it to
start
> from the main frame?

Currently, CreateOpenerProxies always calls CreateOpenerProxiesForFrameTree on
the root node for each discovered FrameTree on the opener chain:

   opener_frame_trees[i]
        ->root()   // <-- here
        ->render_manager()
        ->CreateOpenerProxiesForFrameTree(instance);

This is because multiple nodes may have been pointing at the same FrameTree, so
there may not be a single node on which to call it.  So even if
CreateOpenerProxies is called on a subframe FTN, it would use the root node when
calling CreateOpenerProxiesForFrameTree.

CreateOpenerProxiesForFrameTree doesn't actually need this assumption (most of
its logic is tied to FrameTrees, not specific nodes, and it will work correctly
when called on subframe RFHMs), so the DCHECK is just to convey that today
nobody is calling this on subframes.  Given all this, what should I do with it?

I guess if we keep it, I should also mention the main frame expectation in the
function's comment and remove the unneeded root() below when creating
swapped-out RV.

https://codereview.chromium.org/1309043003/diff/100001/content/browser/site_p...
File content/browser/site_per_process_browsertest.cc (right):

https://codereview.chromium.org/1309043003/diff/100001/content/browser/site_p...
content/browser/site_per_process_browsertest.cc:3013:
embedded_test_server()->GetURL("bar.com", "/frame_tree/2-4.html"));
On 2015/08/31 20:49:43, Charlie Reis wrote:
> Anything specific about this page, or can we use the
cross_site_iframe_factory?

Done - converted to use cross_site_iframe_factory.

https://codereview.chromium.org/1309043003/diff/100001/content/browser/web_co...
File content/browser/web_contents/web_contents_impl.cc (right):

https://codereview.chromium.org/1309043003/diff/100001/content/browser/web_co...
content/browser/web_contents/web_contents_impl.cc:4152: GetSiteInstance(),
nullptr);
On 2015/08/31 20:49:43, Charlie Reis wrote:
> On 2015/08/25 22:38:08, alexmos wrote:
> > Using nullptr keeps today's behavior, but I'm thinking this actually should
> use
> > the target's FTN, because if the opener chain of the source node ever leads
us
> > to the target node, we want to make sure not to try to create a proxy for
the
> > target node in its own SiteInstance (given that I've moved the RVH-based
> > checks).  If you agree, I can add the plumbing to get the target here.
> 
> Interesting.  Is that something we could write a test for?  Sounds worth
fixing.
> 
> (The downside is that this method's name doesn't sound like it's specific to
> postMessage, but in reality I think it is.  The comment in RFHD says it will
> even go away once <webview> fixes some postMessage plumbing.  Incidentally, it
> also claims the method returns the routing ID, which looks stale.)  :)

I wrote a test and then realized this is actually fine.  We actually already
have tests that exercise this (specifically, tests that use "postToOpener" will
end up with this scenario when run with --site-per-process), and this works fine
because of this SiteInstance check in CreateProxyForSiteInstance:
https://code.google.com/p/chromium/codesearch#chromium/src/content/browser/fr...

So I don't think we need to change this.

> 
> >  Or maybe
> > we shouldn't even call EnsureOpenerProxiesExist if
> AreCrossProcessFramesPossible
> > is true (in which case all proxies should've already been created).
> 
> That sounds possibly orthogonal.  We could still hit the issue you describe
> above with only main frames, right?  Or do the RVH checks in
> !AreCrossProcessFramesPossible take care of that?
> 
> Given that this method exists for a <webview> special case, then calling it
only
> when needed might make more sense.

I'll leave this alone for now given my findings above.  

Thinking a bit more, not calling EnsureOpenerProxiesExist if
AreCrossProcessFramesPossible is true isn't actually correct: an example is a 
setup like the SupportCrossProcessPostMessage test, where the swapped-out RVH
needs to be created on-demand when postMessaging the foo window, whether or not
AreCrossProcessFramesPossible is true.  Actually, it will be already created
on-demand due to the window.open("","foo") lookup in the test right before the
postMessage (due to the new opener update logic), but you can imagine
structuring the test slightly differently by getting the foo window reference
from the new_shell2's same-origin opener (main page) instead, in which case
EnsureOpenerProxiesExist would still be necessary.

[Charlie Reis, 2015-09-01 23:37:26]

[+lfg to CC, since this might slightly conflict with
https://codereview.chromium.org/1306053008/, though I don't think it will be
problematic.]

Thanks for reasoning through it.  LGTM.

https://codereview.chromium.org/1309043003/diff/100001/content/browser/frame_...
File content/browser/frame_host/render_frame_host_manager.cc (right):

https://codereview.chromium.org/1309043003/diff/100001/content/browser/frame_...
content/browser/frame_host/render_frame_host_manager.cc:2520:
DCHECK(frame_tree_node_->IsMainFrame());
On 2015/09/01 22:12:27, alexmos wrote:
> On 2015/08/31 20:49:43, Charlie Reis wrote:
> > This doesn't look like it's true.  There's a few call sites above that look
> like
> > they could be made from a subframe RFHM.  Is there a reason you need it to
> start
> > from the main frame?
> 
> Currently, CreateOpenerProxies always calls CreateOpenerProxiesForFrameTree on
> the root node for each discovered FrameTree on the opener chain:
> 
>    opener_frame_trees[i]
>         ->root()   // <-- here
>         ->render_manager()
>         ->CreateOpenerProxiesForFrameTree(instance);
> 
> This is because multiple nodes may have been pointing at the same FrameTree,
so
> there may not be a single node on which to call it.  So even if
> CreateOpenerProxies is called on a subframe FTN, it would use the root node
when
> calling CreateOpenerProxiesForFrameTree.
> 
> CreateOpenerProxiesForFrameTree doesn't actually need this assumption (most of
> its logic is tied to FrameTrees, not specific nodes, and it will work
correctly
> when called on subframe RFHMs), so the DCHECK is just to convey that today
> nobody is calling this on subframes.  Given all this, what should I do with
it?
> 
> I guess if we keep it, I should also mention the main frame expectation in the
> function's comment and remove the unneeded root() below when creating
> swapped-out RV.

Oh, I see.  Yes, that's a little subtle.  I think it's fine to keep as long as
there's a comment about it (either on the check or in the declaration).  If you
do remove the unneeded root() call below, you might want to strengthen it from a
DCHECK to a CHECK (since the method won't do the right thing anymore if we end
up with rare cases where it's called on the subframe).

[alexmos, 2015-09-02 00:02:11]

https://codereview.chromium.org/1309043003/diff/100001/content/browser/frame_...
File content/browser/frame_host/render_frame_host_manager.cc (right):

https://codereview.chromium.org/1309043003/diff/100001/content/browser/frame_...
content/browser/frame_host/render_frame_host_manager.cc:2520:
DCHECK(frame_tree_node_->IsMainFrame());
On 2015/09/01 23:37:26, Charlie Reis (OOO till 9-8) wrote:
> On 2015/09/01 22:12:27, alexmos wrote:
> > On 2015/08/31 20:49:43, Charlie Reis wrote:
> > > This doesn't look like it's true.  There's a few call sites above that
look
> > like
> > > they could be made from a subframe RFHM.  Is there a reason you need it to
> > start
> > > from the main frame?
> > 
> > Currently, CreateOpenerProxies always calls CreateOpenerProxiesForFrameTree
on
> > the root node for each discovered FrameTree on the opener chain:
> > 
> >    opener_frame_trees[i]
> >         ->root()   // <-- here
> >         ->render_manager()
> >         ->CreateOpenerProxiesForFrameTree(instance);
> > 
> > This is because multiple nodes may have been pointing at the same FrameTree,
> so
> > there may not be a single node on which to call it.  So even if
> > CreateOpenerProxies is called on a subframe FTN, it would use the root node
> when
> > calling CreateOpenerProxiesForFrameTree.
> > 
> > CreateOpenerProxiesForFrameTree doesn't actually need this assumption (most
of
> > its logic is tied to FrameTrees, not specific nodes, and it will work
> correctly
> > when called on subframe RFHMs), so the DCHECK is just to convey that today
> > nobody is calling this on subframes.  Given all this, what should I do with
> it?
> > 
> > I guess if we keep it, I should also mention the main frame expectation in
the
> > function's comment and remove the unneeded root() below when creating
> > swapped-out RV.
> 
> Oh, I see.  Yes, that's a little subtle.  I think it's fine to keep as long as
> there's a comment about it (either on the check or in the declaration).  If
you
> do remove the unneeded root() call below, you might want to strengthen it from
a
> DCHECK to a CHECK (since the method won't do the right thing anymore if we end
> up with rare cases where it's called on the subframe).

Thanks, I kept the check and added a comment above it.  I kept the root() as
defense-in-depth, since having it there doesn't really cost us much and may
prevent future bugs.

[alexmos, 2015-09-02 17:12:04]

The CQ bit was checked by alexmos@chromium.org

[alexmos, 2015-09-02 17:12:05]

The patchset sent to the CQ was uploaded after l-g-t-m from creis@chromium.org
Link to the patchset: https://codereview.chromium.org/1309043003/#ps160001
(title: "Add comment for the DCHECK")

[commit-bot: I haz the power, 2015-09-02 17:13:04]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1309043003/160001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1309043003/160001

[commit-bot: I haz the power, 2015-09-02 17:18:49]

Committed patchset #9 (id:160001)

[commit-bot: I haz the power, 2015-09-02 17:19:39]

Patchset 9 (id:??) landed as
https://crrev.com/90325cfabf9c0932eb13b4ed9ace2e3940540f89
Cr-Commit-Position: refs/heads/master@{#346949}