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 23619 - Change MediaKeyError to extend DOMError and use strings for error names
Summary: Change MediaKeyError to extend DOMError and use strings for error names
Status: CLOSED FIXED
Alias: None
Product: HTML WG
Classification: Unclassified
Component: Encrypted Media Extensions (show other bugs)
Version: unspecified
Hardware: All All
: P3 normal
Target Milestone: ---
Assignee: David Dorwin
QA Contact: HTML WG Bugzilla archive list
URL:
Whiteboard:
Keywords:
Depends on: 21798
Blocks:
  Show dependency treegraph
 
Reported: 2013-10-23 20:39 UTC by David Dorwin
Modified: 2014-03-18 15:45 UTC (History)
5 users (show)

See Also:


Attachments

Description David Dorwin 2013-10-23 20:39:19 UTC
All MediaKeyError constants [1] currently begin with "MEDIA_KEYERR_". This was based on the MediaError constants ("MEDIA_ERR_"), but I don't see other examples of this pattern, even in the HTMLMediaElement state constants. Also, the error codes are scoped to MediaKeyError already.

I don't have a specific recommendation for new names; I'd appreciate suggestions for other models to follow.

[1] https://dvcs.w3.org/hg/html-media/raw-file/default/encrypted-media/encrypted-media.html#dom-mediakeyerror
Comment 1 Philip Jägenstedt 2013-10-23 20:49:55 UTC
You should probably just use enum strings instead, that's supported in WebIDL now. The HTMLMediaElement and MediaError APIs aren't a role model here, they were designed before people figured out that integer constants are a bad idea.
Comment 2 David Dorwin 2013-10-29 15:36:27 UTC
Philip: Thanks for the suggestion. Can you point us to an example of an API using enum strings for errors?

In the October 29 telecon, Adrian took an action to make a proposal.

We probably shouldn't make an actual spec change until we know the actual codes we want (bug 21798).
Comment 3 Philip Jägenstedt 2013-10-30 13:06:47 UTC
I don't know about an error enum specifically, but you can look at CanvasFillRule for what the IDL looks like when using enums:

http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#canvasfillrule
Comment 4 Adrian Bateman [MSFT] 2013-11-11 10:07:46 UTC
(In reply to David Dorwin from comment #2)
> Philip: Thanks for the suggestion. Can you point us to an example of an API
> using enum strings for errors?
> 
> In the October 29 telecon, Adrian took an action to make a proposal.
> 
> We probably shouldn't make an actual spec change until we know the actual
> codes we want (bug 21798).

I think the proposal is to change

  interface MediaKeyError {
    const unsigned short MEDIA_KEYERR_UNKNOWN = 1;
    const unsigned short MEDIA_KEYERR_CLIENT = 2;
    const unsigned short MEDIA_KEYERR_SERVICE = 3;
    const unsigned short MEDIA_KEYERR_OUTPUT = 4;
    const unsigned short MEDIA_KEYERR_HARDWARECHANGE = 5;
    const unsigned short MEDIA_KEYERR_DOMAIN = 6;
    readonly attribute unsigned short code;
    readonly attribute unsigned long systemCode;
  };

to

  enum MediaKeyErrorCode { "unknown", "client", "service", "output", "hardware-change", "domain" };

  interface MediaKeyError {
    readonly attribute MediaKeyErrorCode code;
    readonly attribute unsigned long systemCode;
  };
Comment 5 David Dorwin 2013-11-14 08:51:37 UTC
I will get input from the TAG then address along with bug 21798.
Comment 6 Adrian Bateman [MSFT] 2013-11-15 05:36:31 UTC
The advice we have been given is that we should extend DOMError and use the name attribute for the errors. We need to extend DOMError rather than simply reusing it because we need to add the systemCode attribute.

I think this means something like

interface MediaKeyError : DNSError {
  readonly attribute unsigned long systemCode;
};
Comment 7 David Dorwin 2013-12-02 19:22:47 UTC
Updated the summary to reflect the new direction.

Moving in this direction will also allow us to use existing error names (http://www.w3.org/TR/dom/#error-names) where it makes sense. (This could also result in inconsistent implementations if CDMs use these existing names other than as specified in the algorithms or - if we include them - in the Error Codes section of the spec.)

DOMError in the DOM4 WD: http://www.w3.org/TR/dom/#interface-domerror
DOMError in the DOM living specification http://dom.spec.whatwg.org/#interface-domerror

Note: DNSError in comment #6 should be DOMError.
Comment 8 David Dorwin 2014-01-28 01:48:38 UTC
I implemented this change in changeset https://dvcs.w3.org/hg/html-media/rev/953628e21b0a.

However, if systemCode is mainly for debugging and/or logging, I wonder if we should just allow implementations to write a string containing the system code to DOMError's message attribute^. That would allow us to eliminate MediaKeyError and use DOMError directly, which is probably more desirable.

The only loss is that the logging would now be a string (or number parsed from a string). Key system could even choose to use a standard string that makes parsing simple and consistent

^ http://www.w3.org/TR/dom/#dom-domerror-message says "The value of the message will typically be implementation-dependent and for informational purposes only."
Comment 9 David Dorwin 2014-01-28 17:06:03 UTC
If we're unsure whether we need the systemCode attribute, we could start with DOMError and later define MediaKeyError to inherit from DOMError (as currently defined) if we find that such an attribute is necessary. Since the effect would be to add an attribute, this should not affect or break applications as may be the case if we were to later remove MediaKeyError and its additional attribute.
Comment 10 Adrian Bateman [MSFT] 2014-02-21 23:57:18 UTC
(In reply to David Dorwin from comment #9)
> If we're unsure whether we need the systemCode attribute, we could start
> with DOMError and later define MediaKeyError to inherit from DOMError (as
> currently defined) if we find that such an attribute is necessary. Since the
> effect would be to add an attribute, this should not affect or break
> applications as may be the case if we were to later remove MediaKeyError and
> its additional attribute.

We believe that we should keep the systemCode as it is in the spec. The only issue right now is about the future of DOMError, which is in question per the DOM spec. We believe this bug is ready to be resolved fixed.