Bugzilla – Bug 20688
Provide more details on when keyadded should be fired
Last modified: 2013-04-26 21:14:39 UTC
when renewing a license?
The January 14, 2013 version of the spec says:
For each individual key in key, store the individual key... Let did store key be true.
If did store key is true, queue a task to fire a simple event named keyadded at the MediaKeySession object.
This works fine for a simple scenario, but is ambiguous for other scenarios. More generally, what is the purpose of this event? (It originally enabled the app to call play() before responsibility for resuming playback was moved to the UA.)
1) New (unique) key added.
2) New key info added, possibly for an existing key.
3) update() operation completed successfully, regardless of whether it involved addition of a key. (This would likely result in renaming this method.)
Example questions to address:
* Should keyadded be fired once for each key that is added (if a license contains multiple keys)?
* Should keyadded be fired if the key was already known?
* Should keyadded be fired if the license/key policy was updated?
* Should keyadded be fired for successful completion of update() when no further messages need to be sent to the server?
keyAdded was originally intended to indicate a key was successfully added, which was important in an early version. Since playback is automatically started/resumed in the current spec, this event/meaning may no longer be necessary.
We discussed this on the call in February:
The original mental model I had for the session events is as follows:
1) The application has initData, either from needKey or otherwise determined by the application.
2) The applications calls createSession and passes the initdata.
3) The UA fires keymessage and provides the message data that the application sends to a license service.
4) The license service sends back a response, which is passed to the UA with the update() method.
5) The UA may now either go back to step 3 and fire another keymessage, or fire keyadded to indicate that the session process has halted.
This is related to bug 19208, which talks about potentially not firing keymessage. If we did that, we would need keyadded (or something with a different name) to indicate that the session negotiation was done.
Since the February discussion, we have also discussed that CDMs may be initialized asynchronously and the first opportunity for indicating an error is keyerror when a session is created. We may need an additional event to indicate that the session has started following the pattern of progress events.
The description above is not what the spec currently describes. We could change to this model and perhaps rename keyadded to sessionloaded or similar.
I like the simplicity of that model, but I think it is too restrictive. For example, the CDM may need to send keymessage(s) after the initial license exchange. Renewal is one such scenario.
The following is my interpretation of Adrian's proposal during the April 23 f2f:
States (HTMLMediaElement equivalent in parenthesis): Uninitialized, initialized ("loadstart"), keymessage ("progress"), keyadded replacement ("loaded")
I think the last three might be events. The first state is probably implicit.
The keyadded replacement could be useful for a case where the CDM immediately initializes a session with existing material.
This diagram is great. I think this points to the need for another state between keymessage and update to indicate to the app that the CDM is waiting for data. Maybe "notready"?
*** This bug has been marked as a duplicate of bug 21854 ***