This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
The failure case for the MediaKeys constructor confusingly refers to an unknown "new object". " 4.2 Set the new object's error attribute to the error object created in the previous step." No object was created in the previous step. The only object with an "error" attribute is a MediaKeySession object, which is not created by this constructor. Either this step needs to be moved after step 5, and an error attribute added to MediaKeySession, or step 4 needs to be changed to a "throw an exception" step.
The CDM load failure path assumes that the object has been created. I also note that CDM loading is synchronous, which may not be a good idea. How should we handle load failures? If loading is synchronous, the only thing we can do is throw an exception and not create the MediaKeys. If loading is asynchronous, we'd return an un-/partially-initialized MediaKeys object and fire a keyerror at it. This gives us the most flexibility in reporting specific error codes, but I worry about having a MediaKeys that is not fully initialized and no event to say it is initialized. For example, what happens in the (likely) case that the app immediately calls createSession() on the new object? Do we just post a task to handle this once the CDM is ready?
I don't think we have events on MediaKeys yet, do we ? With the current API, I think you have to assume that *both* MediaKeys and MediaKeySession objects can exist whilst the underlying system is still initializing. Finally you will either get a keymessage or a keyerror on the *MediaKeySession* (or presumably more than one of them if you have created more than one) If we can define well enough what it means to have a MediaKeys object vs having a MediaKeySession object then it might make sense to give te MediaKeys a readyState and events to indicate when that changes (e.g. from INITIALIZING to READY or INITIALIZING to ERROR). And then to require that the MediaKeys is in READY state before you can call createSession(). What would be the meaning of a MediaKeys INITIALIZING state ? How would we define that well enough that we don't end up with it being rather browser-specific ?
Discussed in telcon: http://www.w3.org/2013/04/02-html-media-minutes.html#item03 Need text in the spec that explains that you may not see a failure until you create a MediaKeySession object (although a failure prior to this would not impact the application).
The delayed notification is somewhat similar to the resolution of bug 19009 (comment 7, bullet 2 - objects may not be functional until MediaKeys is attached). In fact, that resolution (and the reason for it) basically requires delayed reporting: The error cannot be fired/thrown until the CDM is loaded, which may not occur until the MediaKeys object is attached to the HTMLMediaElement, which must happen after the constructor completes. However, I'm not sure of the best way to report a load error. I think the requirements are: * We must allow asynchronous initialization of MediaKeys, CDM, etc. - both for performance and to allow UAs to prompt the user, if necessary, without blocking the main thread. * Loading and other initialization errors must be fired/thrown after the constructor returns. * We must give the application an opportunity to set an error event handler or handle an exception. (Note that like keymessage/keyerror resulting from createSession(), even firing the error immediately should allow the application to set a handler before the event gets processed.) * Obviously, the object we are throwing the error must support error events (MediaKeys does not currently). My thoughts: * I think it is odd to report that an unrelated operation (MediaKeys creation) failed in response to a separate operation (createSession() call), even if the former is a prerequisite. * It would be nice to avoid adding events to another object (MediaKeys). This would require yet another event handler for most apps. (Are there other errors that would be better to fire at the MediaKeys instead of the MediaKeySession? If so, this might be a non-issue.) * We've discussed states and events for MediaKeySession lifetime. Are they also needed for MediaKeys? (As above, if they are not needed for other reasons, it would be preferable to avoid them.) * setMediaKeys() could throw an exception if the MediaKeys failed to initialize, but there is no guarantee that the load will have completed by then and we don't want to block on this call.
The session life cycle is tracked in bug 21854. This may impact our options for addressing this bug and/or be influenced by this bug.
I've tried to make the appropriate changes here: https://dvcs.w3.org/hg/html-media/rev/d55c97f5d3a4
The above change added the following synchronous step to createSession()'s algorithm. "If there is a MediaKeyError stored with the MediaKeys object that occurred because of an error loading the cdm then queue a task to fire a simple event named error at the MediaKeySession object and abort these steps." However, CDM loading may not may not have completed yet, which might mean we miss such an error and/or continue with steps before the CDM is ready. I recommend: a) Move this step to the asynchronous steps. b) Before that step, insert a new step to wait for CDM initialization (initiated in the MediaKeys constructor) has not completed, wait for it to complete.
Fixed: https://dvcs.w3.org/hg/html-media/rev/2719b617426e