[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 #28 from David Dorwin <ddorwin@google.com> ---
I made some minor changes to Jerry's changeset in
https://dvcs.w3.org/hg/html-media/rev/a3759a1510ea.

I addressed resume in https://dvcs.w3.org/hg/html-media/rev/6f23a0371a5a and
https://dvcs.w3.org/hg/html-media/rev/eb3f8e2d323c.

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."

If we can answer these questions, I think we can close this bug.

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

Received on Thursday, 22 May 2014 23:29:27 UTC