The current set of error codes  is from the original draft, before we had implementation and use experience. We should revisit the list and define a new permanent set.
Resolution of this bug should consider bug 16737 and bug 21795.
*** Bug 21795 has been marked as a duplicate of this bug. ***
*** Bug 16737 has been marked as a duplicate of this bug. ***
*** Bug 16617 has been marked as a duplicate of this bug. ***
We discussed this on the telcon:
I think the outcome of the discussion was along these lines:
1) We should have error codes for things that it would make sense to tell a user that would be actionable. These error codes should be defined in the spec in a generic way that is shared across implementations.
2) We need to ensure that the error codes are described in sufficient detail that they are interpreted unambiguously by different implementers.
3) More granular, possibly system-specific, error codes are required for sites to use for debugging and potentially live telemetry to help identify customer issues. If these different errors are unlikely to be usefully described to customers then the system specific systemCode might be enough for this requirement.
We need implementers to review their possible error codes and identify those that can be actionably be reported to users.
Here is what I would see Adobe Access using as errors:
-- We would use this for debugging, but these are generally unrecoverable
-- We would use this to say that we failed to install or initialize the CDM
-- This could be actionable if the user has the option to deny the CDM from being installed and/or launched
-- This could translate to any number of service related errors on our side for example: activation failure, license acquisition failure, in-band authentication failure, etc.
-- I think making this actionable requires more detail, which could be provide by a systemCode.
-- We would use this to handle all output related errors.
-- This is typically actionable by the user by unplugging the offending output devices.
-- This seems like a dup to me of the above error code and we would not use it.
-- We would use this to represent domain specific service errors.
-- This would be actionable by attempting to re-register to the domain.
I would like to see an additional error -- MEDIA_KEYERR_EXPIRED
-- We would use this to represent that the current key(s) have expired and need to be re-requested
-- This is actionable and the solution is to re-create the session
To add more clarity to my request for a new error code -- this could be handled today by sending another key request. However I am not clear on whether a key request can be sent whenever the CDM wants to i.e. not in response to a "Generate Request". If that is allowed, then I would not need this.
Two additional errors that would be generic (i.e. keysystem-independent) would be:
- message error: a message provided by update() was malformed or failed integrity checking
- wrong key: the key(s) provided via update() are not the correct one(s) for the content (e.g. KID does not match)
I would like to see the install/update and initialize broken into separate errors. The install/update will only happen when the CDM itself changes, but the initialize may happen the first time a web application uses EME.
I would also like to see an error like "platform capabilities not available". This is different from the output case, for example in cases where the content provider is requesting hardware key support and the platform does not provide it.
I would expect the application to respond by requesting an alternate content stream.
(In reply to comment #7)
> - wrong key: the key(s) provided via update() are not the correct one(s) for
> the content (e.g. KID does not match)
It seems this would be hard to determine. We don't require initData to list KIDs that are expected and there could be multiple sessions. This also seems like a mistake rather than something that the application should message to the user or could handle.
Once we have identified the errors we want to cover, we need to decide whether to add a transition (and accompanying spec text) from the READY state to the ERROR state. MEDIA_KEYERR_OUTPUT is the best current example of where this might be necessary.
See https://www.w3.org/Bugs/Public/show_bug.cgi?id=21854#c20 and the telecon minutes from 2013-10-01.
FYI, issue 23619 tracks potential renaming of all errors.
Should the ERROR state be terminal? In the current state machine, it appears to be so.
Some scenarios to consider:
* Output protection error: the session might have other keys whose requirements can be met when new media data is provided. Should we really require that a new session be created (along with the accompanying message exchange and associated latency)?
* License renewal: If a license expires because it cannot be renewed (i.e. lost network connection) then can subsequently be renewed, should we require that the application start over with a new license request when it could just provide a renewal message (via update())?
(In reply to David Dorwin from comment #13)
> Should the ERROR state be terminal? In the current state machine, it appears
> to be so.
I don't think it should always be terminal.
> Some scenarios to consider:
> * Output protection error: the session might have other keys whose
> requirements can be met when new media data is provided. Should we really
> require that a new session be created (along with the accompanying message
> exchange and associated latency)?
I assume you mean MEDIA_KEYERR_OUTPUT specifically. This is sometimes recoverable. MEDIA_KEYERR_HARDWARECHANGE I would not expect to be recoverable. We have still not nailed down the differences between MEDIA_KEYERR_OUTPUT and MEDIA_KEYERR_HARDWARECHANGE but this is one of them.
> * License renewal: If a license expires because it cannot be renewed (i.e.
> lost network connection) then can subsequently be renewed, should we require
> that the application start over with a new license request when it could
> just provide a renewal message (via update())?
MEDIA_KEYERR_SERVICE or MEDIA_KEYERR_DOMAIN may be be recoverable. But how this gets resolved is key system and server specific. I would expect these errors to be followed with a keyrequest message, which the application would then have to deal with to recover.
If errors are not terminal, does the ERROR state make sense?
As an example, if an error has fired and the session is in the ERROR state but the session contains a valid key for the current frame, should it decrypt it or not?
I started a thread with proposed errors:
With the move to have MediaKeyError extend DOMError (bug 23619), we can also consider using some of the existing DOMError names (http://www.w3.org/TR/dom/#error-names) where it makes sense instead of creating new ones.
I removed the old error codes and constants in changeset https://dvcs.w3.org/hg/html-media/rev/953628e21b0a. These will be replaced with error names (https://dvcs.w3.org/hg/html-media/raw-file/default/encrypted-media/encrypted-media.html#mediakeyerror-names).
Based on our implementation experience so far, we don't think that a generic classification for errors is likely to lead to a different error message being shown to the user. Almost all of our errors fall into the "unknown" category.
We understand the general principle of wanting to tell users if there is something they can do to try to correct the issue (something in their configuration) or if there is nothing that they can do. We're just not sure at this point that we can produce a readily interoperable list. Our experience is that without the implementation-specific systemCode, diagnosing issues is difficult.
I recommend that we just keep a general error for v1.
From Bug 25199:
Since the use of Promises means that not all categories of errors will result in an error event and corresponding setting of the error attribute, we may want to reconsider the current behavior of using a simple event with error attribute. We may instead want to fire a complex event or use some other mechanism.
We may also need to resolve the DOMExceptions reported in the promises with the MediaKeyError - currently derived from DOMError - used to report other errors.
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.
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.
To simplify discussion of the current issues, I've moved my previous comment to bug 26372 and am closing this one.
*** This bug has been marked as a duplicate of bug 26372 ***