This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 16617 - Consider more granular error reporting
Summary: Consider more granular error reporting
Status: RESOLVED DUPLICATE of bug 21798
Alias: None
Product: HTML WG
Classification: Unclassified
Component: Encrypted Media Extensions (show other bugs)
Version: unspecified
Hardware: All All
: P3 normal
Target Milestone: ---
Assignee: Adrian Bateman [MSFT]
QA Contact: HTML WG Bugzilla archive list
Depends on: 16857
  Show dependency treegraph
Reported: 2012-04-03 16:23 UTC by Mark Watson
Modified: 2013-04-23 18:38 UTC (History)
6 users (show)

See Also:


Description Mark Watson 2012-04-03 16:23:31 UTC
MEDIA_ERR_ENCRYPTED covers three cases
1) No key was provided and no needkey handler was provided
2) The provided key could not be successfully applied
3) The user agent does not support decryption of this media data

Consider whether these should be differentiated ?

A single error is consistent with the current broad error codes, though that may be something that should be improved in general. It seems that except for #1, which should only occur in applications that do not support encrypted media, these are all application bugs and not something that would improve the user experience. Any unique handling of the error codes by an application would essentially be describing a bug type. Unique codes might be helpful in tracking down the cause of the bug, but there are probably other options. It is also possible that some of these cases should be reported via MediaKeyErrorEventInit.
Comment 1 David Dorwin 2012-04-13 22:45:31 UTC
Note that "MediaKeyErrorEventInit" in the above text should be "MediaKeyErrorEvent". This is covered by issue 16740.
Comment 2 David Dorwin 2012-04-27 21:01:02 UTC
We should also consider whether it makes sense to add any new MediaError values related to encryption. Consider the following for each of the use cases listed above.

1) Is there any precedent for checking for a handler this way? It seems to add complexity to user agent implementations. WebKit, for example, just queues events in the HTMLMediaElement and does not directly access the handlers. If we we cannot or do not want to have this check, we need to remove this use case.

The purpose of this use case is reporting errors to pages that do not have a needkey handler, possibly because they were created before it was defined). Without an error, these pages might not be informed that playback will not succeed. Maybe we can fire another event or find some other way to address this. This would most likely be generic player pages rather than content provider pages since the latter would most likely update their pages before adding encrypted content.

2) As noted in bug 16857, we may need to remove this use case. If so, this scenario would result in MEDIA_ERR_DECODE.

3) This could be handled by existing error codes

Possible causes include:
 A) The user agent not supporting encrypted media
 B) The user agent not support encrypted media in the container format
 C) The CDM does not support [decoding] the codec(s).

(A) would require that the user agent can detect the media is encrypted even though it has no decryption capabilities. This seems unlikely. If it did, MEDIA_ERR_SRC_NOT_SUPPORTED could be used.
(B) could be reported as MEDIA_ERR_SRC_NOT_SUPPORTED.
(C) could be reported as MEDIA_ERR_SRC_NOT_SUPPORTED or maybe MEDIA_ERR_DECODE.

On the other hand, as noted in the FAQ, MEDIA_ERR_ENCRYPTED was added to avoid confusion (ambiguity). The FAQ also notes that MediaKeyErrors may not be fatal to playback where as MediaErrors are fatal.

Depending on the decisions, we may want to rename MEDIA_ERR_ENCRYPTED. Also, we should be more specific about what errors should be returned in the cases above.
Comment 3 Adrian Bateman [MSFT] 2012-08-28 21:10:30 UTC
Assigned to Adrian to follow-up. More errors is better but we need them to be consistent across CDMs.
Comment 4 Adrian Bateman [MSFT] 2013-04-23 18:23:22 UTC
Bug 21798 is the placeholder for considering what error codes we should have.

*** This bug has been marked as a duplicate of bug 21798 ***
Comment 5 David Dorwin 2013-04-23 18:38:16 UTC
I was just about to add "MediaError" to the summary. This bug relates to the single new MediaError code that is added. Most of the cases are covered by other bugs, though, so we can probably leave this closed.