[Android] Avoid using ContentViewCore when detaching from RWHVAndroid

[Android] Avoid using ContentViewCore when detaching from RWHVAndroid

The shutdown sequence for a given WebContents involves the
ContentViewCore detaching itself from WebContentsViewAndroid. This in
turn detaches the ContentViewCore from RenderWidgetHostViewAndroid.
However, as the state of the ContentViewCore may be inconsistent during
shutdown, calls into ContentViewCore during detachment may be
unreliable.

Avoid such calls by caching the WindowAndroid exposed by
ContentViewCore; the window has stronger lifetime guarantees and can
safely be used during detachment.

BUG=479878, 464642
Committed: https://crrev.com/039f8ee45bcdcc61bf62f1f1f18a92b6a4a3958a
Cr-Commit-Position: refs/heads/master@{#327401}

[jdduke (slow), 2015-04-28 18:38:01]

jdduke@chromium.org changed reviewers:
+ sievers@chromium.org

[jdduke (slow), 2015-04-28 18:38:01]

sievers@: I haven't been able to repro any of the crashes/issues from
crbug.com/479878 and crbug.com/464642. Tried an asan build and everything.

This fix should at least address the immediate issue (and allow cherry-picking
to M43) while we figure out a longer term solution.

What I'm thinking is that we need a much stronger pairing contract between
ContentViewCore/RHWVAndroid. Perhaps we could exchange a coupling object that
can be invalidated when the connection is lost, by either party. That way we
don't have all of the fragile WebContentView/RenderWidgetHostView lookups from
ContentViewCore when it is destroyed or the renderer process is destroyed.

Without a solid repro, however, I'd like to land something like this before
going down that road. Thoughts?

https://codereview.chromium.org/1103213003/diff/40001/content/browser/rendere...
File content/browser/renderer_host/render_widget_host_view_android.h (right):

https://codereview.chromium.org/1103213003/diff/40001/content/browser/rendere...
content/browser/renderer_host/render_widget_host_view_android.h:338:
ui::WindowAndroid* content_view_core_window_android_;
I'm not married to this name.

|current_window_android_|? |active_window_android_|? |content_view_window_|?

[no sievers, 2015-04-28 21:07:58]

https://codereview.chromium.org/1103213003/diff/60001/content/browser/rendere...
File content/browser/renderer_host/render_widget_host_view_android.cc (right):

https://codereview.chromium.org/1103213003/diff/60001/content/browser/rendere...
content/browser/renderer_host/render_widget_host_view_android.cc:1433:
layer_->RemoveFromParent();
Why did you make this change?

It seems to change the behavior since CVC::RemoveLayer() does more:
It might make its solid color layer drawable if there are not other children.

[jdduke (slow), 2015-04-28 21:58:45]

https://codereview.chromium.org/1103213003/diff/60001/content/browser/rendere...
File content/browser/renderer_host/render_widget_host_view_android.cc (right):

https://codereview.chromium.org/1103213003/diff/60001/content/browser/rendere...
content/browser/renderer_host/render_widget_host_view_android.cc:1433:
layer_->RemoveFromParent();
On 2015/04/28 21:07:58, sievers wrote:
> Why did you make this change?
> 
> It seems to change the behavior since CVC::RemoveLayer() does more:
> It might make its solid color layer drawable if there are not other children.

Ah, last time I looked at that method (long time ago) it just changed the
ancestry, but it looks like there are more side effects. Regardless, I don't
*think* this change was necessary, as the layer_ seems to be (is likely) null in
the crash reports I'm seeing. I'll undo this change.

[no sievers, 2015-04-28 22:06:00]

lgtm

[jdduke (slow), 2015-04-28 22:15:09]

The CQ bit was checked by jdduke@chromium.org

[commit-bot: I haz the power, 2015-04-28 22:16:29]

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

[commit-bot: I haz the power, 2015-04-29 00:22:27]

Committed patchset #5 (id:80001)

[commit-bot: I haz the power, 2015-04-29 00:23:19]

Patchset 5 (id:??) landed as
https://crrev.com/039f8ee45bcdcc61bf62f1f1f18a92b6a4a3958a
Cr-Commit-Position: refs/heads/master@{#327401}