[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 #31 from David Dorwin <ddorwin@google.com> ---
(In reply to Jerry Smith from comment #30)
> Do you have a specific proposal on this?  I assume you are thinking that
> createSession/loadSession promise waits would be used to communicate waiting
> for a key.  The completed promise would then allow playback to resume. 
> Correct?

I'm not sure what you mean, but here is a rough proposal.

Add the following to HTMLMediaElement:
  readonly attribute Promise<any> waitingForKey;

The promise would be resolved in the Queue a "waiting" Event algorithm.

The promise object behind the attribute would be replaced in the Attempt to
Resume Playback If Necessary algorithm before queueing the canplay event[1].

As explained below, the replacement is somewhat complex because there is no
obvious point when the promise should be reset (i.e. the application calling a
method). Applications will need to know to listen to the "canplay" event, and
we still might have a race condition. Maybe we can improve these areas. The
current text is also a bit complicated for similar reasons.


[1] Specifically, I propose the following text (the text of steps 1, 4, and 5
are unchanged)

1. Let the media element be the specified HTMLMediaElement object.
2. If the promise represented by the waitingForKey attribute on the media
element is not resolved, abort these steps.
3. Set the waitingForKey attribute on the media element to a new promise.
4. Attempt to resume the resource fetch algorithm by running the Encrypted
Block Encountered algorithm. 
5. If the user agent can advance the current playback position in the direction
of playback, queue a task to fire a simple event named canplay at the media
element.

Note that a new promise is created before attempting to resume. If the resume
fails, that promise will also be resolved. This ensures that the promise is
"reset" even if playback cannot advance for other reasons. If an application
happens to get that promise and there is still a key missing, that promise will
also be rejected.

In any case, applications should listen for the "canplay" event and call
.then() on the new promise.

There might be some race condition around step 2 above and another call to this
algorithm (i.e. two update() calls close together while resume is still in
progress).

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

Received on Monday, 16 June 2014 20:53:42 UTC