Bug 103262
| Summary: | .activeCues should not be null once a non-disabled track was added | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Antoine Quint <graouts> |
| Component: | Media | Assignee: | Nobody <webkit-unassigned> |
| Status: | NEW | ||
| Severity: | Normal | CC: | ahmad.saleem792, eric.carlson, webkit-bug-importer |
| Priority: | P2 | Keywords: | InRadar, WPTImpact |
| Version: | 528+ (Nightly build) | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| URL: | http://wpt.live/html/semantics/embedded-content/media-elements/interfaces/TextTrack/activeCues.html | ||
Antoine Quint
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
<rdar://problem/12756204>
Ahmad Saleem
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.