Oilpan: Move WebFrameWidgetImpl into Oilpan heap.

Oilpan: Move WebFrameWidgetImpl into Oilpan heap.

The allocation and deallocation scheme of this class' instance is a bit
unusual, because these instances are passed to the Chromium side. The contract
between Chromium and us is basically: "call close() when you finish using it".
WebFrameWidgetImpl::create() calls leakRef() to keep the object alive, and
WebFrameWidgetImpl::close() does deref() to free up the object.

To mimic this keep-alive semantics in the Oilpan world, SelfKeepAlive<> is
used.

This patch fixes a raw pointer in WebFrameWidgetImpl.

BUG=509911
R=haraken@chromium.org, oilpan-reviews@chromium.org, sigbjornf@opera.com

Committed: https://src.chromium.org/viewvc/blink?view=rev&revision=200800

[haraken, 2015-08-18 08:03:08]

https://codereview.chromium.org/1294293004/diff/1/Source/web/WebFrameWidgetIm...
File Source/web/WebFrameWidgetImpl.cpp (right):

https://codereview.chromium.org/1294293004/diff/1/Source/web/WebFrameWidgetIm...
Source/web/WebFrameWidgetImpl.cpp:132: m_client = nullptr;

Can we clear m_layerTreeView, m_rootLayer, m_rootGraphicsLayer and
m_currentInputEvent as well?

Now that WebFrameWidgetImpl is on the heap, its destruction is delayed until the
next GC happens. Any raw pointer in an on-heap object has a risk of becoming a
stale pointer. We need to clear those raw pointers in an explicit clear point
(like here) or verify that they don't become stale.

[Yuta Kitamura, 2015-08-18 08:33:59]

https://codereview.chromium.org/1294293004/diff/1/Source/web/WebFrameWidgetIm...
File Source/web/WebFrameWidgetImpl.cpp (right):

https://codereview.chromium.org/1294293004/diff/1/Source/web/WebFrameWidgetIm...
Source/web/WebFrameWidgetImpl.cpp:132: m_client = nullptr;
On 2015/08/18 08:03:08, haraken wrote:
> 
> Can we clear m_layerTreeView, m_rootLayer, m_rootGraphicsLayer and
> m_currentInputEvent as well?
> 
> Now that WebFrameWidgetImpl is on the heap, its destruction is delayed until
the
> next GC happens. Any raw pointer in an on-heap object has a risk of becoming a
> stale pointer. We need to clear those raw pointers in an explicit clear point
> (like here) or verify that they don't become stale.
> 

Done.

[haraken, 2015-08-18 08:40:14]

LGTM

[Yuta Kitamura, 2015-08-19 04:18:51]

The CQ bit was checked by yutak@chromium.org

[commit-bot: I haz the power, 2015-08-19 04:19:03]

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

[commit-bot: I haz the power, 2015-08-19 04:40:27]

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

[commit-bot: I haz the power, 2015-08-19 04:40:28]

Try jobs failed on following builders:
  linux_chromium_gn_dbg on tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)

[Yuta Kitamura, 2015-08-19 04:41:28]

The CQ bit was checked by yutak@chromium.org

[commit-bot: I haz the power, 2015-08-19 04:41:32]

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

[dcheng, 2015-08-19 05:17:50]

dcheng@chromium.org changed reviewers:
+ dcheng@chromium.org

[dcheng, 2015-08-19 05:17:51]

Note: I don't think there's anything that actually requires that this class be
refcounted. Would it make sense to just move it unconditionally into the Oilpan
heap?

[commit-bot: I haz the power, 2015-08-19 06:09:03]

Committed patchset #2 (id:20001) as
https://src.chromium.org/viewvc/blink?view=rev&revision=200800