Decide on ideal "waitingforkey" event behavior when update() doesn't resume playback

[ddorwin]

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.)
2. 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 "tracked" sessions: Does "record of key usage" need not be updated each time a block is decrypted? #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.

[ddorwin]

I'd like feedback from authors, but I'm leaning towards 1) always firing the event and b) removing the text to ensure consistent behavior. This seems like the easiest to implement and test, and we have already identified concerns related to that text.

[ddorwin]

Note that the following Note related to the " may choose to skip " statement in setMediaKeys() is misleading because the user agent may just be waiting for a MediaKeys object to be specified (see #8).

For example, the user agent may skip this step if mediaKeys has no sessions.

I also have more general concerns about how the algorithms wait and resume playback in #100.

[paulbrucecotton]

1.Is the subsequent "waitingforkey" event desirable? (Note: There may be further events on subsequent update() calls.)

The Sapporo F2F attendees discussed this item and agreed with what @ddorwin proposed in "1) always firing the event".

◦This would involve removing the text allowing "The user agent... to skip this step if it knows resuming will fail."

There was a preference by Sapporo F2F attendees for removing the above text as suggested by @ddorwin.

It would still would be good to get application developers feedback on these proposed changes. @mwatson2 and @steelejoe will attempt to get such feedback.

[mwatson2]

Feedback from our application developers aligns with the above: send the event after every update() that does not contain the needed key.

[ghost]

I agree with @ddorwin's proposal here.

[joeyparrish]

@ddorwin's proposal sounds good to me.

[ddorwin]

Note: I do not believe there will be multiple "waitingforkey" events because the Queue a "waitingforkey" Event algorithm does not actually queue an event if waiting for key is already true.