[Bug 25923] isTypeSupported should be asynchronous

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

--- Comment #31 from David Dorwin <ddorwin@google.com> ---
(In reply to Anne from comment #30)
> What I care about is what's observable and whether the programming flow is
> identical across user agents.
> 
> If isTypeSupported() starts returning something other than "maybe" in some
> user agents before create() is invoked, that would bad.

If it is a standard value with defined expectations/behavior, then I don't
think it is necessarily bad. I would be more concerned about information
leakage.

> If all user agents required create() (which I assume is asynchronous) before
> isTypeSupported() started returning something other than "maybe", and that
> was stipulated in the specification, that would work.

This is not one of the options - isTypeSupported() is static and should not
depend on loading the CDM, which is the purpose of create().

> It seems however that you likely want to invoke isTypeSupported() before you
> invoke create() at which point I'm back to comment 0.

I think this assumes that the value returned by isTypeSupported() is different
depending on whether the CDM is permitted/installed.

If the user does not permit the CDM, the UA could return "". Alternatively, if
the UA always returned "maybe", the application would try MediaKeys.create(),
which would be rejected with "NotSupportedError" per step 3 of the create()
algorithm. The effect is the same - the user does not get to play the encrypted
content.

Things get more complicated if a user agent supports multiple such key systems.
In that case, the application could make use of the difference between not
allowed ("") and allowed ("maybe" or "probably"). A combination that returns
"maybe" does not guarantee it will work, and a robust application _should_ be
able to try other "maybe" combinations that it supports. I acknowledge that
this is probably not common.


One possible solution for this case would be to add "deferred" to the
IsTypeSupportedResult enum. This would be an indication that yes the
combination can be supported by the user agent but the application must try
MediaKeys.create(). This also avoids leaking information since the UA would
always return this value, at least the first time an origin attempts to use a
key system. Applications would prefer "probably" combinations to "maybe"
combinations to "deferred" combinations. If "deferred" is returned for multiple
key systems, the application would need to try each of them. One issue is that
the two key systems might support different media streams, which might mean the
pre-fetched streams would need to be discarded.


Alternatively, the application could return "maybe"/"probably" the first time
isTypeSupported() is called on an origin then prompt the user on create(). In
most cases, the prompt will be accepted and things will work as expected
(without complicating every playback by making isTypeSupported() asynchronous).
If the user declines the prompt, create() would fail. Again, supporting
multiple key systems (or even flavors of a single key system) causes problems
here - the user would likely need to be told to refresh the page.


I can imagine cases where on key system [flavor] is declined and the
application should try another. Maybe we should specify an iterative process
for applications rather than check-and-expect-success. Naming can help imply
the expected behavior - maybe we should replace create() with something like
requestKeySystem().

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

Received on Tuesday, 16 September 2014 20:53:37 UTC