Use NoBaseWillBeGarbageCollectedFinalized for VRController as other LocalFrame supplements in modul…

Use NoBaseWillBeGarbageCollectedFinalized for VRController as other LocalFrame supplements in modules.

Unfortunately this means, that VRController cannot be used as Member in other
classes, so VRController has to be obtained from LocalFrame.

BUG=540848
Committed: https://crrev.com/46b002b681f5c4afbbaa79f45049251a71c3e5a5
Cr-Commit-Position: refs/heads/master@{#352956}

[ostap, 2015-10-07 20:29:31]

sl.ostapenko@samsung.com changed reviewers:
+ bajones@chromium.org

[ostap, 2015-10-07 21:05:15]

sl.ostapenko@samsung.com changed reviewers:
+ haraken@chromium.org, thestig@chromium.org

[bajones, 2015-10-07 21:11:40]

LGTM!

If you don't mid I'd like to understand a bit more about why
NoBaseWillBeGarbageCollectedFinalized is the appropriate type here. (I still
haven't quite gotten the hang of Oilpan's intricacies.)

[ostap, 2015-10-07 21:30:14]

On 2015/10/07 21:11:40, bajones wrote:
> LGTM!
> 
> If you don't mid I'd like to understand a bit more about why
> NoBaseWillBeGarbageCollectedFinalized is the appropriate type here. (I still
> haven't quite gotten the hang of Oilpan's intricacies.)

I also don't understand this completely.
Here I just copied approach used in other modules (like geolocation,
permissions, encryptedmedia, storage & etc), but cannot get why it should be
this way.
From what I see, LocalFrame has map of OwnPtr-ed Members and on de-allocation of
LocalFrame it clears this map (m_supplements). As I understand, VRController
should be deallocated later by garbage collector, but garbage collector asserts
on invalid pointer or magic.
Since all other modules use NoBaseWillBeGarbageCollectedFinalized, I assumed
that this is somewhat known problem and gave up investigating.

In any case, waiting for your final lgtm (or not ;)

[Lei Zhang, 2015-10-07 21:37:35]

thestig@chromium.org changed reviewers:
- thestig@chromium.org

[Lei Zhang, 2015-10-07 21:39:19]

Sorry, I just commented on the bug. I don't know anything about this code -->
not a Blink reviewer.

[bajones, 2015-10-07 21:39:37]

On 2015/10/07 21:30:14, ostap wrote:
> On 2015/10/07 21:11:40, bajones wrote:
> > LGTM!
> > 
> > If you don't mid I'd like to understand a bit more about why
> > NoBaseWillBeGarbageCollectedFinalized is the appropriate type here. (I still
> > haven't quite gotten the hang of Oilpan's intricacies.)
> 
> I also don't understand this completely.
> Here I just copied approach used in other modules (like geolocation,
> permissions, encryptedmedia, storage & etc), but cannot get why it should be
> this way.
> From what I see, LocalFrame has map of OwnPtr-ed Members and on de-allocation
of
> LocalFrame it clears this map (m_supplements). As I understand, VRController
> should be deallocated later by garbage collector, but garbage collector
asserts
> on invalid pointer or magic.
> Since all other modules use NoBaseWillBeGarbageCollectedFinalized, I assumed
> that this is somewhat known problem and gave up investigating.
> 
> In any case, waiting for your final lgtm (or not ;)

You've already got my LGTM. Code consistency is always good, I just wanted to
understand it a bet better personally. Thanks!

[ostap, 2015-10-07 21:50:58]

The CQ bit was checked by sl.ostapenko@samsung.com

[commit-bot: I haz the power, 2015-10-07 21:51:37]

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

[commit-bot: I haz the power, 2015-10-07 22:00:20]

Committed patchset #1 (id:1)

[commit-bot: I haz the power, 2015-10-07 22:02:13]

Patchset 1 (id:??) landed as
https://crrev.com/46b002b681f5c4afbbaa79f45049251a71c3e5a5
Cr-Commit-Position: refs/heads/master@{#352956}

[haraken, 2015-10-07 23:12:55]

LGTM