NEW103262
.activeCues should not be null once a non-disabled track was added 
https://bugs.webkit.org/show_bug.cgi?id=103262
Summary .activeCues should not be null once a non-disabled track was added
Antoine Quint
Reported 2012-11-26 08:36:07 PST
We fail the Opera-submitted test for TextTrack's .activeCues property. The first three tests fail because the <track default> element added dynamically via the DOM API contains no cues, and thus we have the .activeCues property still set to null, even though .mode = "showing" was set. Opera sets it to an empty TextTrackCueList object. Reading the spec about activeCues (http://www.whatwg.org/specs/web-apps/current-work/multipage/the-video-element.html#dom-texttrack-activecues), this is a bug on our end as .activeCues should no longer be returning null once a TextTrack has a non-disabled mode. We have the same issue when .mode = "hidden" where we're still returning null instead of an empty TextTrackCueList. This is what happens when calling .addTextTrack(), which creates a hidden text track, not a disabled one.
Attachments
Add attachment proposed patch, testcase, etc.
Antoine Quint
Comment 1 2012-11-27 01:53:25 PST
<rdar://problem/12756204>
Ahmad Saleem
Comment 2 2023-10-12 13:08:28 PDT
We still fail few test cases here: https://wpt.fyi/results/html/semantics/embedded-content/media-elements/interfaces/TextTrack/activeCues.html?label=experimental&label=master&aligned= Although doing better than Blink but worse than Firefox.
Note You need to log in before you can comment on or make changes to this bug.