[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 #38 from David Dorwin <ddorwin@google.com> ---
(In reply to Jerry Smith from comment #37)
> I carried over timeupdate to be consistent with the readyState steps you
> pointed out.  
> 
> The timeupdate event is supposed to fire when “The current playback position
> changed as part of normal playback or in an especially interesting way, for
> example discontinuously.”  Based on that, I believe it should be removed
> from the waiting steps in EME.

Sounds good.

> I also agree with updating the resume steps to handle the playing case.  I
> believe the model is to provide both the canplay and playing events.  I
> propose inserting the playing event as a new step 5:
> 
> "5.  If the element's paused attribute is false, the user agent must queue a
> task to fire a simple event named playing at the element."

Sounds good. We need to check that the resume was successful first, right?
Maybe we need to restructure step 4 to block the new #5 as well (unless there
is a separate condition for "playing".

> Do you have specific race conditions you think we need to manage?  Comment
> 31 specifically mentions two update() calls close together while resume is
> still in progress.  This might result in out of order resume/wait outcomes. 
> Is that your area of concern?

No, I haven't thought through the non-promises case since I wrote the changeset
in comment #28. There were obviously some in the promises case, though. Let's
address the items above then ask people to review.

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

Received on Friday, 11 July 2014 22:08:03 UTC