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

This sounds fine to me.

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

Thank you for your previous feedback, Jerry
Travis, Jerry and watchers of w3c archive, I have an update for which I would like further feedback:

Today, I've filed https://github.com/whatwg/html/issues/2531 which may result in changing the API name and type to be a `FrozenArray<DOMString> messages` field rather than a single `DOMString message` for reasons listed in the WHATWG issue and copied here:

Implementations may have multiple items of error message information available, all related to the same error condition. Indeed, in Chromium, we have precisely this situation (a top-level media engine status string that is slightly more detailed than just the MediaError.code enum, as well as potentially multiple, varying in granularity/specificity, error messages from things like the media parser portion of the media engine.)

Attempts to relay this information in an interoperable way to web apps using just a single DOMString result in either:

  1.  A readily machine-parsable, but with unstandardized structure, aggregation of such strings (such as a serialized JSONObject, or a newline-delimited and more human-readable listing of the strings, or
  2.  A reduction in the granularity and detail of potentially critical error message information produced by the implementation to fit the message within a single string.

Option 1 results in a de-facto standard if web apps begin to expect to be able to use a JSON parser, but not all implementations would have this nor would there be any official standardization of the format or structure.
Option 2 limits the utility of this feature in general. The whole point is to provide additional error detail to enable web apps to aggregate and debug common, sometimes hard-to-repro, error conditions in media playback.

Potential solution:
A reasonable mitigation of these two options would be to simply change the type (and name) of the field to a FrozenArray<DOMString> field, empty if there is no additional info beyond that available in MediaError.code, otherwise one or more informative strings.

Potential extension to this solution (see also https://github.com/whatwg/html/issues/2531#issuecomment-293997756):
Also, would it make sense to provide a non-normative expectation that the messages in a sequence of multiple strings in this proposed messages field start as a general message and later ones are more specific? This is how I was planning to implement the original #2085 in Chromium.
Please respond with any feedback around this proposed change to HTML MediaError.

Matt

On Fri, Dec 2, 2016 at 2:43 PM, Jerry Smith (WPT) <jdsmith@microsoft.com<mailto:jdsmith@microsoft.com>> wrote:
>
> 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<mailto:wolenetz@google.com>]
> Sent: Wednesday, November 30, 2016 2:12 PM
> To: Travis Leithead <travis.leithead@microsoft.com<mailto:travis.leithead@microsoft.com>>; Jerry Smith (WPT) <jdsmith@microsoft.com<mailto:jdsmith@microsoft.com>>; www-archive@w3.org<mailto: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