Initial implementation of AudioTrack, AudioTrackList, VideoTrack, and VideoTrackList.

Source/core/html/track/TrackBaseList.h

+// Copyright 2014 The Chromium Authors. All rights reserved.
+// Use of this source code is governed by a BSD-style license that can be
+// found in the LICENSE file.
+
+#ifndef TrackBaseList_h
+#define TrackBaseList_h
+
+#include "core/dom/ActiveDOMObject.h"
+#include "core/events/EventTarget.h"
+#include "core/html/HTMLMediaElement.h"
+
+namespace WebCore {
+
+class GenericEventQueue;
+class TrackBase;
+
+class TrackBaseList : public RefCounted<TrackBaseList>, public EventTargetWithInlineData, public ActiveDOMObject {

[philipj_slow, 2014/03/13 10:00:04]

As per the other comment, it doesn't seem like this ought to be a
ActiveDOMObject, because it shouldn't have its own event queue ("task source" in
the spec parlance) nor remove pending events at any point. If there's any spec
change that would simplify the implementation I think it is still malleable, see
e.g. https://www.w3.org/Bugs/Public/show_bug.cgi?id=24710

[acolwell GONE FROM CHROMIUM, 2014/03/18 22:02:15]

Agreed. I plan on changing the code to use the event queue in HTMLMediaElement.

+    REFCOUNTED_EVENT_TARGET(TrackBaseList);
+
+public:
+    explicit TrackBaseList(HTMLMediaElement*);
+    virtual ~TrackBaseList();
+
+    unsigned length() const { return m_tracks.size(); }
+    TrackBase* getByIndex(unsigned index) const;
+    TrackBase* getById(const AtomicString& id) const;
+    unsigned getIndex(const AtomicString& id) const;
+
+    DEFINE_ATTRIBUTE_EVENT_LISTENER(change);
+    DEFINE_ATTRIBUTE_EVENT_LISTENER(addtrack);
+    DEFINE_ATTRIBUTE_EVENT_LISTENER(removetrack);
+
+    // EventTarget interface
+    virtual ExecutionContext* executionContext() const OVERRIDE;
+
+    // ActiveDOMObject interface
+    virtual bool hasPendingActivity() const OVERRIDE;
+    virtual void stop() OVERRIDE;
+
+    void shutdown();
+
+    void add(TrackBase*);
+    void remove(const String& id);

[philipj_slow, 2014/03/13 10:00:04]

Should be AtomicString as in the getters?

Request for education: Since id is an arbitrary string, won't some hash table
used for interning the strings be filled with things only seen once? How do I
pick between String and AtomicString when writing new code?

[acolwell GONE FROM CHROMIUM, 2014/03/18 22:02:15]

You are probably right. There appeared to be a trend of making strings returned
by JS attributes AtomicStrings, but in this case you are right that these are
likely to always be unique or at least unique enough to not be worth using
AtomicString. I'll change all the ID instances to use String.

+    void removeAll();
+
+    void scheduleChangeEvent();
+
+private:
+    void scheduleTrackEvent(const AtomicString& eventName, PassRefPtr<TrackBase>);
+
+    bool m_shutdown;
+    Vector<RefPtr<TrackBase> > m_tracks;
+    OwnPtr<GenericEventQueue> m_asyncEventQueue;
+};
+
+}
+
+#endif