18181 2012-07-18 17:34:54 +0000 <track> The cues don't seem to be cleared when setting a new src="". 2013-06-06 03:18:26 +0000 1 1 1 Unclassified HTML WG HTML5 spec unspecified Other other RESOLVED FIXED http://www.whatwg.org/specs/web-apps/current-work/#sourcing-out-of-band-text-tracks CR P3 normal --- 1 contributor silviapfeiffer1 mike philipj public-html-admin public-html-wg-issue-tracking robin silviapfeiffer1 zcorpan public-html-bugzilla oldest_to_newest 70828 0 contributor 2012-07-18 17:34:54 +0000 This was was cloned from bug 17059 as part of operation convergence. Originally filed: 2012-05-15 11:36:00 +0000 ================================================================================ #0 contributor@whatwg.org 2012-05-15 11:36:53 +0000 -------------------------------------------------------------------------------- Specification: http://www.whatwg.org/specs/web-apps/current-work/multipage/the-video-element.html Multipage: http://www.whatwg.org/C#sourcing-out-of-band-text-tracks Complete: http://www.whatwg.org/c#sourcing-out-of-band-text-tracks Comment: The cues don't seem to be cleared when setting a new src="". Posted from: 88.131.66.80 by simonp@opera.com User agent: Opera/9.80 (Macintosh; Intel Mac OS X 10.7.3; U; en) Presto/2.10.229 Version/11.62 ================================================================================ #1 Philip J 2012-05-23 08:24:50 +0000 -------------------------------------------------------------------------------- What we've implemented is to clear the cues synchronously when setting a new source, but to start loading asynchronously. Unless this is silly, this is what we'd like to have spec'd. ================================================================================ #2 Simon Pieters 2012-05-23 09:47:37 +0000 -------------------------------------------------------------------------------- Please spec this as prose outside the loading algorithm, saying something like "When the src attribute is set, changed, or removed, all cues in the track element's TextTrack's TextTrackCueList object must be removed." (Doing it in the loading algorithm at the monitoring step means that if you change src, add a cue, and change src again, that cue won't be dropped, because the algorithm has moved on to the waiting step, which doesn't match my expectation or what Philip implemented.) ================================================================================ 88793 1 silviapfeiffer1 2013-06-06 03:18:26 +0000 EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the Editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the Tracker Issue; or you may create a Tracker Issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Accepted Change Description: https://github.com/w3c/html/commit/4fa62833aaf76632345c917268f0c47aa82c5bcf Rationale: Adopted WHATWG resolution Now reads: + Whenever a <code>track</code> element has its <code + title="attr-track-src">src</code> attribute set, changed, or + removed, the user agent must synchronously empty the element's + text track's text track list of cues. + (This also causes the algorithm above to stop adding cues from the + resource being obtained using the previously given URL, if any.)