Fix RenderFrameProxyHost::GetRenderViewHost for subframes.

Fix RenderFrameProxyHost::GetRenderViewHost for subframes.

Also a speculative fix for an Android crash report.

BUG=406048
TEST=Open NTP with --site-per-process.

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

[Charlie Reis, 2014-08-22 18:15:15]

https://codereview.chromium.org/496283006/diff/1/content/browser/frame_host/r...
File content/browser/frame_host/render_frame_proxy_host.cc (right):

https://codereview.chromium.org/496283006/diff/1/content/browser/frame_host/r...
content/browser/frame_host/render_frame_proxy_host.cc:56: return
frame_tree_node_->frame_tree()->GetRenderViewHost(site_instance_);
This follows the pattern from InitRenderFrameProxy below.

It's still possible for it to return null if the frame tree doesn't have a RVH
for this SiteInstance (maybe a timing issue?), but this at least works for the
subframe case when render_frame_host_ is null.

[nasko, 2014-08-22 18:18:04]

Thanks for finding this one and fixing it! LGTM

https://codereview.chromium.org/496283006/diff/1/content/browser/frame_host/r...
File content/browser/frame_host/render_frame_proxy_host.cc (right):

https://codereview.chromium.org/496283006/diff/1/content/browser/frame_host/r...
content/browser/frame_host/render_frame_proxy_host.cc:56: return
frame_tree_node_->frame_tree()->GetRenderViewHost(site_instance_);
On 2014/08/22 18:15:15, Charlie Reis wrote:
> This follows the pattern from InitRenderFrameProxy below.
> 
> It's still possible for it to return null if the frame tree doesn't have a RVH
> for this SiteInstance (maybe a timing issue?), but this at least works for the
> subframe case when render_frame_host_ is null.

The RVH should be created before any RFH/RFPH objects are created, so I think we
should be safe. If I'm wrong, we will be proven wrong fairly easily ;).
I also like that we are now consistent within the file.

[Charlie Reis, 2014-08-22 18:18:34]

The CQ bit was checked by creis@chromium.org

[commit-bot: I haz the power, 2014-08-22 18:19:53]

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

[commit-bot: I haz the power, 2014-08-22 20:05:27]

FYI, CQ is re-trying this CL (attempt #1).
The failing builders are:
  android_chromium_gn_compile_rel on tryserver.chromium.linux
(http://build.chromium.org/p/tryserver.chromium.linux/builders/android_chromiu...)
  android_dbg_tests_recipe on tryserver.chromium.linux
(http://build.chromium.org/p/tryserver.chromium.linux/builders/android_dbg_tes...)
  linux_chromium_rel_swarming on tryserver.chromium.linux
(http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)

[commit-bot: I haz the power, 2014-08-22 20:08:07]

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

[commit-bot: I haz the power, 2014-08-22 20:08:09]

Try jobs failed on following builders:
  android_chromium_gn_compile_rel on tryserver.chromium.linux
(http://build.chromium.org/p/tryserver.chromium.linux/builders/android_chromiu...)

[Charlie Reis, 2014-08-22 20:14:35]

The CQ bit was checked by creis@chromium.org

[commit-bot: I haz the power, 2014-08-22 20:16:18]

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

[commit-bot: I haz the power, 2014-08-22 21:31:01]

Committed patchset #1 (1) as 291506