W3C home > Mailing lists > Public > public-html-bugzilla@w3.org > October 2011

[Bug 14260] <track> "text tracks ready" and HTMLMediaElement.readyState

From: <bugzilla@jessica.w3.org>
Date: Fri, 28 Oct 2011 12:26:37 +0000
To: public-html-bugzilla@w3.org
Message-Id: <E1RJlW9-00064m-6F@jessica.w3.org>

--- Comment #24 from Philip Jägenstedt <philipj@opera.com> 2011-10-28 12:26:35 UTC ---
(In reply to comment #22)
> Hmm... I started speccing this, and I'm not sure I'm 100% comfortable with some
> of the implications here.
> What exactly are we blocking on? Consider what happens if a text track is
> removed from a media element, is disabled, or is enabled, between the <track>
> element being parsed and the </video> tag being parsed. Which ones should
> block? What about tracks that are dynamically added? Consider a setTimeout()
> script racing the parser to add or remove something from the list, or an
> onerror handler on a <track> that updates the src="", racing with the parser:
>    <video>
>      <track ... onerror="update track src">
>      ...
>    </video>
> Exactly which tracks should we wait for?

Hmm, exactly what problem are we trying to solve? If it is only to block first
play (auto or manual) when there are tracks in the markup, then a working but
kludgy solution would be to consider only the <track> elements that are
children of <video> at the time that </video> is parsed.

As for an error event handler changing src, I suggest that a track be
considered "ready" the first time it either loads or fails.

However, if the entire point is to not play while the tracks are loading,
perhaps we shouldn't fiddle with readyState but instead cause the transition
from paused to playing to block on track readiness? That way changing the
active tracks on a playing resource doesn't stall, but if it was paused it
won't play until the tracks are ready. Would that work?

Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
Received on Friday, 28 October 2011 12:26:39 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:02:06 UTC