SVGViewSpec wrapper should keep its context SVGSVGElement wrapper alive.

SVGViewSpec wrapper should keep its context SVGSVGElement wrapper alive.

There seems to be some cases where a SVGSVGElement wrapper is gc-ed while the SVGSVGElement is alive.
However, |m_transform| and other properties held by SVGViewSpec manage its lifetime via the SVGSVGElement v8 wrapper.

This patch avoids the situation by keeping the context SVGSVGElement wrapper alive from SVGViewSpec wrapper.

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

[kouhei (in TOK), 2014-06-04 06:57:22]

haraken, pdr: Would you take a look?

I confirmed that this will fix the fuzzer case.

However I'm stuck writing a LayoutTest for this. I can't reproduce the case
where the wrapper goes away while the element is alive. According to haraken,
the wrapper going away while SVGSVGElement is alive itself is a bug. The wrapper
should be kept alive while the element is alive to keep the expandos put on the
wrapper.

[haraken, 2014-06-04 07:15:39]

Although it's a shame that you cannot write a test case for this (and thus don't
know what's actually causing the bug), I think this CL is doing a right thing.

LGTM. Let's wait for an approval of pdr@.

[pdr., 2014-06-05 02:33:14]

On 2014/06/04 07:15:39, haraken wrote:
> Although it's a shame that you cannot write a test case for this (and thus
don't
> know what's actually causing the bug), I think this CL is doing a right thing.
> 
> LGTM. Let's wait for an approval of pdr@.

I don't think I can approve this one. This affects all channels and will
presumably be merged into them all. I'm not comfortable merging a patch where we
neither understand the bug nor have a test, even though the patch itself makes
sense, because of the possibility of causing additional regressions.

This doesn't necessarily have to fall on Kouhei though. Could we loop the
security team in on creating a better test?

[pdr., 2014-06-09 03:06:54]

Could you investigate whether we have the same issue with other tearoff types
(e.g., SVGMatrix and friends)?

https://code.google.com/p/chromium/issues/detail?id=379998#c21 addresses my
concerns with this patch. Thank you for taking the time to find the root cause.
I'd like a real test if possible but I don't think we should hold up this patch
and other bugs for it.

[kouhei (in TOK), 2014-06-09 03:48:38]

> https://code.google.com/p/chromium/issues/detail?id=379998#c21 addresses my
> concerns with this patch. Thank you for taking the time to find the root
cause.
> I'd like a real test if possible but I don't think we should hold up this
patch
> and other bugs for it.
I'm landing this as we confirmed that this is a correct fix.
As described in the bug, writing a LayoutTest case for this is difficult :/

[kouhei (in TOK), 2014-06-09 03:48:40]

The CQ bit was checked by kouhei@chromium.org

[kouhei (in TOK), 2014-06-09 03:48:43]

The CQ bit was checked by kouhei@chromium.org

[commit-bot: I haz the power, 2014-06-09 03:48:53]

CQ is trying da patch. Follow status at
 https://chromium-status.appspot.com/cq/kouhei@chromium.org/315893002/40001

[kouhei (in TOK), 2014-06-09 03:52:58]

On 2014/06/09 03:06:54, pdr wrote:
> Could you investigate whether we have the same issue with other tearoff types
> (e.g., SVGMatrix and friends)?
We don't have this issue in SVGMatrixTearOff, as we already have a strong
reference to contextElement in SVGTransform.idl.

[commit-bot: I haz the power, 2014-06-09 04:42:21]

Change committed as 175772