This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 20688 - Provide more details on when keyadded should be fired
Summary: Provide more details on when keyadded should be fired
Status: RESOLVED DUPLICATE of bug 21854
Alias: None
Product: HTML WG
Classification: Unclassified
Component: Encrypted Media Extensions (show other bugs)
Version: unspecified
Hardware: All All
: P3 normal
Target Milestone: ---
Assignee: Adrian Bateman [MSFT]
QA Contact: HTML WG Bugzilla archive list
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 19809 20622 20689
  Show dependency treegraph
 
Reported: 2013-01-16 23:16 UTC by David Dorwin
Modified: 2013-04-26 21:14 UTC (History)
4 users (show)

See Also:


Attachments

Description David Dorwin 2013-01-16 23:16:52 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.)

Possible purposes:
 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?
Comment 1 David Dorwin 2013-04-23 16:32:18 UTC
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.
Comment 2 Adrian Bateman [MSFT] 2013-04-23 17:03:05 UTC
We discussed this on the call in February:
http://www.w3.org/2013/02/05-html-media-minutes.html

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.
Comment 3 David Dorwin 2013-04-23 20:29:44 UTC
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.
Comment 4 David Dorwin 2013-04-23 23:06:57 UTC
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.
Comment 6 Joe Steele 2013-04-25 02:38:52 UTC
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"?
Comment 7 David Dorwin 2013-04-26 21:14:39 UTC

*** This bug has been marked as a duplicate of bug 21854 ***