Oilpan: add transition types to track interface objects.

Source/core/html/track/LoadableTextTrack.h

Index: Source/core/html/track/LoadableTextTrack.h
diff --git a/Source/core/html/track/LoadableTextTrack.h b/Source/core/html/track/LoadableTextTrack.h
index 944722019f6c84bd96971a815127bfbc579fc8b7..88719b6b1492ab6eb88f91c4d0efbbc08e9cbf11 100644
--- a/Source/core/html/track/LoadableTextTrack.h
+++ b/Source/core/html/track/LoadableTextTrack.h
@@ -28,6 +28,7 @@
 
 #include "core/html/track/TextTrack.h"
 #include "core/loader/TextTrackLoader.h"
+#include "platform/heap/Handle.h"
 #include "wtf/PassRefPtr.h"
 
 namespace WebCore {
@@ -37,9 +38,9 @@ class LoadableTextTrack;
 
 class LoadableTextTrack FINAL : public TextTrack, private TextTrackLoaderClient {
 public:
-    static PassRefPtr<LoadableTextTrack> create(HTMLTrackElement* track)
+    static PassRefPtrWillBeRawPtr<LoadableTextTrack> create(HTMLTrackElement* track)
     {
-        return adoptRef(new LoadableTextTrack(track));
+        return adoptRefWillBeRefCountedGarbageCollected(new LoadableTextTrack(track));
     }
     virtual ~LoadableTextTrack();
 
@@ -50,11 +51,15 @@ public:
 
     size_t trackElementIndex();
     HTMLTrackElement* trackElement() { return m_trackElement; }
+#if !ENABLE(OILPAN)
     void clearTrackElement();
+#endif
 
     virtual bool isDefault() const OVERRIDE { return m_isDefault; }
     virtual void setIsDefault(bool isDefault) OVERRIDE  { m_isDefault = isDefault; }
 
+    virtual void trace(Visitor*) OVERRIDE;
+
 private:
     // TextTrackLoaderClient
     virtual void newCuesAvailable(TextTrackLoader*) OVERRIDE;
@@ -67,7 +72,7 @@ private:
 
     HTMLTrackElement* m_trackElement;

[haraken, 2014/04/23 01:51:45]

Can't this become a RawPtrWillBeWeakMember? (Probably is it not yet safe to use
a (Weak)Member to the Node hierarchy?)

If we need to keep it as a raw pointer, I think we also need to keep
clearTrackElement() in oilpan builds as well. Otherwise, m_trackElement can
become a stale pointer (although I don't know if it causes any real issue in
this specific case).

[Mads Ager (chromium), 2014/04/23 05:59:38]

This is slightly annoying. We have to use RefPtrs and not Members into the Node
hierarchy for a little while more. However, weak members are fine. The problem
with using Member is that the node hierarchy is not yet properly traced and
therefore a Member to a Node does not keep the entire tree alive the way it
should. I'm working on that. WeakMembers are not intended to keep anything
alive, so they work as they should. So, for now this should probably be a weak
member.
I think this should really be a strong pointer though. Once a LoadableTextTrack
is associated with an HTMLTrackElement they belong together and should live and
die together. We should have strong pointers between them to ensure that. Once
we have that we don't have to clear anything. In general, we should use strong
pointers over weak pointers whenever it makes sense and it seems to me that it
makes a lot of sense to use strong pointers in most of this code.

[Mads Ager (chromium), 2014/04/23 06:10:11]

We should probably make this a WeakMember for now. Could you add a "FIXME:
Oilpan: This should be a strong pointer once Member pointers into the Node
hierarchy can be used." Then I can find it and update it when I make that
change.

[sof, 2014/04/23 07:36:48]

Did that just that & adopted haraken's RawPtrWillBeWeakMember suggestion, along
with a comment.

Leaving it raw pointer in the Oilpan case might cause trouble if you take
HTMLTrackElement.track and put it inside another text track list (looks unusual,
but I think that's possible). The object could then live longer and possibly
access the invalid pointer.

     Timer<LoadableTextTrack> m_loadTimer;
-    OwnPtr<TextTrackLoader> m_loader;
+    OwnPtrWillBeMember<TextTrackLoader> m_loader;
     KURL m_url;
     bool m_isDefault;
 };