[Webkit-unassigned] [Bug 117815] Fix TextTrackCue::cueIndex() to handle the null case of TextTrack::cues(() properly

[bugzilla-daemon at webkit.org]

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





--- Comment #12 from Ruth Fong <ruthiecftg at gmail.com>  2013-07-02 10:32:15 PST ---
(In reply to comment #10)
> According to that change list:
> 
> However, per HTML rules, a track object returns a non-NULL
> cue list object only if cues haven't been disabled. The
> problem is that in the case for an inband text track, the
> cues are disabled by default, and so the track object
> returns NULL as the value of the cue list pointer. As
> currently implemented, the text track cue object assumes
> that the track's cue list is always non-NULL, but this
> crashes the browser when the pointer value is dereferenced
> to get the cue index.
> 
> Need to verify this is the case; if so, we should probably file a new bug.

>From whatWG spec (http://www.whatwg.org/specs/web-apps/current-work/#dom-texttrack-cues):
"If the text track mode of the text track that the TextTrack object represents is not the text track disabled mode, then the cues attribute must return a live TextTrackCueList object that represents the subset of the text track list of cues of the text track that the TextTrack object represents whose end times occur at or after the earliest possible position when the script started, in text track cue order. Otherwise, it must return null. When an object is returned, the same object must be returned each time."

>From w3 spec (http://www.w3.org/html/wg/drafts/html/master/embedded-content-0.html#text-track-disabled):
"Disabled: Indicates that the text track is not active. Other than for the purposes of exposing the track in the DOM, the user agent is ignoring the text track. No cues are active, no events are fired, and the user agent will not attempt to obtain the track's cues."

The last part of the w3 definition makes me a bit wary ("the user agent will not attempt to obtain the track's cues"), but the chromium patch makes sense in terms of whatWG's spec.

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