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>
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]
> 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