[Bug 21798] Revisit the need for new DOMException names and the "error" attribute and event (was: MediaKeyError codes)

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

David Dorwin <ddorwin@google.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|Revisit MediaKeyError codes |Revisit the need for new
                   |                            |DOMException names and the
                   |                            |"error" attribute and event
                   |                            |(was: MediaKeyError codes)

--- Comment #21 from David Dorwin <ddorwin@google.com> ---
The following is a reboot of this bug and discussion in light of the many
changes to the spec since this bug was filed.

*** Summary ***
 * Many scenarios are now covered by promises and DOMException names (section
I.A.).
 * MediaKeyError (in its current form) will be eliminated (bug 25896).
 * There are a few remaining event-type scenarios to handle (section I.B.).
 * A simple “error” event with a corresponding attribute does not seem to make
sense (section II.).
 * There are few, if any, new DOMException names needed (section I.). However,
we may need to define a new set of enum values if we adopt a non-error solution
(section II.).
 * We can always start simple / with no new names or enums and add
functionality if implementation experience shows it is useful and possible (see
also comment #19). It will be easier to add such functionality than to remove
it once it's deployed.


*** I. Scenarios ***
The following sections list some of the errors and other events that UAs and
CDMs might want to report to applications. Many of the previous use cases for
MediaKeyError have been replaced with promises and normative text in the
algorithms that defines which DOMException name to use. These are covered in
the first section.

** A. Errors reported via promises **
The following scenarios are handled by promises returned by EME methods,
especially MediaKeys.create() and MediaKey.createSession(). Where relevant, the
normatively-defined error name or the normative text that allows the proposed
error name is specified. For these "common" scenarios, we may want to add
explicit normative steps with these error names to avoid relying on
“appropriate error name”.

Note that most conditions that result in NotSupportedError should also result
in a negative response from isTypeSupported(), especially if it is made
asynchronous (bug 25923), providing the opportunity to check more of these
conditions.

1. CDM is not supported: NotSupportedError (normative)
2. CDM is not installed/available: NotSupportedError (“appropriate error name”
when “cdm fails to load or initialize”)
3. CDM is disabled: NotSupportedError (“appropriate error name” when “cdm fails
to load or initialize”)
4. CDM was denied necessary permissions (e.g. unique identifier):
NotSupportedError (“appropriate error name” when “cdm fails to load or
initialize”)
5. CDM could not be loaded/instantiated: NotSupportedError? (“appropriate error
name” when “cdm fails to load or initialize”)
6. Invalid license (or other response) format: InvalidAccessError (normative)
7. Other failures (i.e. fatally failed to find or use root of trust): TBD - If
no other appropriate value, potentially UnknownError (defined by Indexed DB)

** B. Issues reported asynchronously during playback ***
The following are issues/errors that will occur during media playback rather
than as the result of EME calls. These would (currently - see section II.) be
reported via the “error” attribute when an “error” event is reported.

Note that these are not fatal to playback. Playback can resume when the issue
is addressed.
Note also that some are or will be addressed in other ways.
We might be able to replace the generic “error” event with some other more
specific and useful mechanisms.

Key availability / valid window:
1. No key (key not available): addressed by waiting and waitingFor.
2. Expired key (key was available but its use has expired): TimeoutError? Do we
need an error or is this the same as “no key”?
3. Expired key due to unsuccessful key renewal or heartbeat: same as #2
4. Outside the allowed window of time: Key is available but it’s valid time is
in the future: TBD. (#2 "Expired key" could also fall into this category or
absorb the future case.)
5. Number of playbacks exceeded (and similar policies): treat as #2 “expired”?
6. Instructed to stop by license server: treat as #2 “expired”?

Note that all of the above _could_ be handled by waiting/waitingFor, at least
for now.

Output protection:
7. Key available but could not be used due to output protection requirements
that are not met: TBD. Maybe we should see how the other output
protection-related issues are addressed before defining a new name.
8. Content is being downscaled due to output protection requirements of an
available key that are not currently met: TBD, but not really an error.


*** II. Error/Event Reporting ***
As discussed in section I.B., such events are not fatal “errors” and may
potentially be covered by other EME APIs. In addition, it’s unclear when the
“error” attribute should be cleared or how to handle/report multiple errors.

We could make the “error” event a non-simple event so that it can include a
DOMException. I’m not sure how this fits with the architectural direction for
error reporting. We could decide that these are really informational and thus
do not need to use DOMException.

With the key availability / valid window scenarios being potentially covered by
waiting/waitingFor and no clarity in how to handle output protection, maybe it
is easiest to skip reporting such events for now.

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

Received on Thursday, 17 July 2014 18:05:26 UTC