RE: Request for input on WHATWG adding a message field to MediaError object in HTML5

Hi Matt,

We agree with adding a DOMString message to MediaError.  You are correct that the Microsoft implementation currently returns a long msExtendedCode that serves a similar purpose.  Returning additional error information is important to communicate what error state occurred.

Jerry

From: Matt Wolenetz [mailto:wolenetz@google.com]
Sent: Wednesday, November 30, 2016 2:12 PM
To: Travis Leithead <travis.leithead@microsoft.com>; Jerry Smith (WPT) <jdsmith@microsoft.com>; www-archive@w3.org
Subject: Request for input on WHATWG adding a message field to MediaError object in HTML5

Hi Travis, Jerry and watchers of w3c archive -

On behalf of requests from users of Media Source Extensions API and HTMLMediaElement in general, I've filed a WHATWG spec issue [1] to request the addition of an implementation-specific informative string message field to the MediaError object. Since this looks like it has consensus in WHATWG, and is only missing some interop tests before it lands in that spec, I presume it would eventually arrive in the w3c HTML spec, too.

This mail is to request advance input from w3c folks who may not participate in WHATWG about this upcoming addition to the HTML spec.

If I understand correctly, Edge already has a prefixed "msExtendedCode" [2] and FF nightly/aurora builds have their own version [3] of this message field already. Chromium is considering adding similar [4], which is why I filed the WHATWG issue [1] to get this standardized rather than add another variant to a bunch of varying, sometimes prefixed, implementation-specific interfaces.

Why is this needed?

Currently, the MediaError object only allows standardized exposure of a very small enumeration of error codes [5]. Web authors have requested greater detail of errors, even if they are exposed in vendor-specific messages.

A common example is that MSE (Media Source Extensions) emits MEDIA_ERR_DECODE and MEDIA_ERR_SRC_NOT_SUPPORTED from a large variety of places in the spec, and differentiating the actual reason for the error is difficult at best. Services that deliver content via HTMLMediaElement (with or without MSE) and that encounter MediaError errors in the user agent frequently need more detail than just MediaError.code from the user agent to diagnose content, web app or user agent problems, especially when those errors are hard-to-reproduce.

I believe there is consensus reached on the WHATWG side that a new non-nullable "message" DOMString field be added to MediaError, populated at time of MediaError creation with either an empty string or an implementation-specific error message string if the implementation wishes to provide more precise error details.

Please respond with any feedback around this proposed addition to HTML MediaError.

Thank you,
Matt Wolenetz
(Chrome SWE, W3C MSE spec co-editor)

[1] https://github.com/whatwg/html/issues/2085

[2] https://developer.microsoft.com/en-us/microsoft-edge/platform/documentation/apireference/interfaces/mediaerror/

[3] https://dxr.mozilla.org/mozilla-central/source/dom/webidl/MediaError.webidl

[4] https://bugs.chromium.org/p/chromium/issues/detail?id=601086#c12

[5] https://www.w3.org/TR/html52/semantics-embedded-content.html#error-codes