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

M59 Chrome and Opera (46) will contain support for MediaError.message
<https://html.spec.whatwg.org/multipage/embedded-content.html#dom-mediaerror-message>,
letting developers obtain greater detail about a MediaError produced by
<audio> or <video>. If detail is available, the message will generally
contain an error descriptor, optionally followed by a “:” and further error
detail. (Though the format is left vendor-specific in the WHATWG spec,
Firefox had already shipped their message in a similar format, so Chrome
followed along to help interop, following discussion in WHATWG.)

We may attempt standardization also of a separate field containing just the
error descriptor, to lessen interop concerns and web app parsing burdens.

On Mon, Apr 17, 2017 at 2:41 PM, Matt Wolenetz <wolenetz@google.com> wrote:

> 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/platfor
>> m/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
>>
>
>