[Bug 20991] MediaKeys constructor: make CDM loading asynchronus and fix load failure algorithm

https://www.w3.org/Bugs/Public/show_bug.cgi?id=20991

David Dorwin <ddorwin@google.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|MediaKeys constructor       |MediaKeys constructor: make
                   |failure case refers to      |CDM loading asynchronus and
                   |unknown "new object".       |fix load failure algorithm

--- Comment #4 from David Dorwin <ddorwin@google.com> ---
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.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Thursday, 25 April 2013 05:56:13 UTC