[Bug 18515] Provide more details on behavior of the media element when the key for an encrypted block is not available

https://www.w3.org/Bugs/Public/show_bug.cgi?id=18515

--- Comment #36 from David Dorwin <ddorwin@google.com> ---
Back to the waitingFor solution, which is already implemented in the spec, we
should address the following comments I made in comment #28:

> It's difficult to document when to call canplay on resume since there can be
> multiple blocked tracks. I think the text is sufficient to describe the
> desired behavior, though.
> 
> I didn't see an answer to this question: Why is timeupdate fired? The
> current playback position hasn't changed, but I guess this is consistent
> with the steps for "If the previous ready state was HAVE_FUTURE_DATA or
> more, and the new ready state is HAVE_CURRENT_DATA or less" in HTML5.
> 
> I did not add a step to fire "timeupdate" when resuming. It's not fired "If
> the new ready state is HAVE_ENOUGH_DATA" is in HTML5.
> 
> Do we need to add the following to the resume steps (in addition to
> "canplay")?
> "if the element's paused attribute is false, queue a task to fire a simple
> event named playing at the element."

We may also want to look at corner cases, alternative paths, race conditions,
etc. like those I identified for a possible promises-based solution in comment
#31 and comment #32.

Jerry (and others), please review and reply to the comments above. Once we're
satisfied with the resolutions (and that there are not any corner cases we're
missing), we can close this bug. I think we're close.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Tuesday, 8 July 2014 21:43:05 UTC