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

http://www.w3.org/Bugs/Public/show_bug.cgi?id=14260

--- Comment #32 from Simon Pieters <simonp@opera.com> 2011-11-14 10:14:07 UTC ---
(In reply to comment #29)
> So:
> 
> - if the media element is still on a stack of open elements, then abort the
> resource selection algorithm at the top.

I'm not so happy with this. This sounds like something browsers will want to
work around by speculatively running the resource selection algorithm to
preload the right <source>. (Consider the case where there are external scripts
inside the video which block the parser from seeing the </video> end tag.) If
we can avoid blocking loading of <source>, I think it would be good.

> - when a media element is popped off a stack of open elements, run the resource
> selection algorithm.
> - when the resource selection algorithm is started, flag any <track> elements
> in the media element as being load-blocking text tracks.
> - when a text track loads or fails to load, clear its load-blockingness.
> - prevent transition to HAVE_FUTURE_DATA when there are any tracks in the media
> element's list of text tracks that are load-blocking.
> 
> Sound right?

How about:

- When resource selection starts, if the media element is on a stack of open
elements, set wait_for_pop to true.
- When a media element is popped off the stack of open elements, set
wait_for_pop to false and set load-blocking on any <track> children (that are
not already loaded or have failed to load).
- When a text track loads of fails to load, clear its load-blockingness.
- Prevent transition to HAVE_FUTURE_DATA when wait_for_pop is true or there are
any tracks in the media element's list of text tracks that are load-blocking.

-- 
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 Monday, 14 November 2011 10:14:22 UTC