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

Some updates from the last week: Firefox has already shipped a 'message'
DOMString field, and Chrome will likely do similar soon. So a 'messages'
FrozenArray<DOMString> field is becoming less likely as a replacement, and
may not ever be standardized.

Matt

On Mon, Apr 17, 2017 at 2:38 PM, Travis Leithead <
travis.leithead@microsoft.com> wrote:

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