[Webkit-unassigned] [Bug 103262] New: .activeCues should not be null once a non-disabled track was added

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=103262

           Summary: .activeCues should not be null once a non-disabled
                    track was added
           Product: WebKit
           Version: 528+ (Nightly build)
          Platform: Unspecified
               URL: http://w3c-test.org/html/tests/submission/Opera/media/
                    interfaces/TextTrack/activeCues.html
        OS/Version: Unspecified
            Status: UNCONFIRMED
          Severity: Normal
          Priority: P2
         Component: Media Elements
        AssignedTo: webkit-unassigned at lists.webkit.org
        ReportedBy: graouts at apple.com
                CC: eric.carlson at apple.com,
                    webkit-bug-importer at group.apple.com


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.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.