[encrypted-media] Decide on ideal "waitingforkey" event behavior when update() doesn't resume playback

ddorwin has just created a new issue for 
https://github.com/w3c/encrypted-media:

== Decide on ideal "waitingforkey" event behavior when update() 
doesn't resume playback ==
This issue is related to the user agent behavior when playback is 
already blocked waiting for a key (the `"waitingforkey"` event has 
already been fired) and `update()` is called but does not unblock 
playback (i.e. by providing the needed key). (This was originally 
raised in the latter comments of issue #42.) We need to decide on the 
desired application-visible behavior then make any related changes to 
the algorithms.

Note: The `update()` call may not have provided _any_ keys. For 
example, it could have been part of a series of messages to obtain a 
key.

Currently, the _Attempt to Resume Playback If Necessary_ algorithm 
runs the _Encrypted Block Encountered_ algorithm, which I believe 
would get to the 'Run the queue a "waitingforkey" event algorithm on 
the media element' step, resulting in another `"waitingforkey"` event.

However, the call sites for "Attempt to Resume Playback If Necessary 
algorithm" say "The user agent may choose to skip this step if it 
knows resuming will fail." Thus, the behavior could be inconsistent, 
even within key system implementations.

Two questions:

1. Is the subsequent `"waitingforkey"` event desirable? (Note: There 
may be further events on subsequent `update()` calls.)
1. Should we ensure that the behavior is consistent?
  * That is, should we ensure that the `"waitingforkey"` event is 
always called by requiring that the _Attempt to Resume Playback If 
Necessary_ algorithm always runs?
  * This would involve removing the text allowing "The user agent... 
to skip this step if it knows resuming will fail."
    * That might be a good thing as discussed in (unrelated) issue 
#83.
    * Note that the reality is that this text _does_ affect the 
observable behavior (whether the event is fired), something that was 
not captured in that discussion.

See https://github.com/w3c/encrypted-media/issues/98

Received on Tuesday, 13 October 2015 18:18:43 UTC