-
Notifications
You must be signed in to change notification settings - Fork 2.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Include a "message" field in MediaError object #2085
Comments
MediaError is such a strange design. Ah well. This seems reasonable to me, but could you explain why it's not better to expand the list of media error codes? Is the concern backward compatibility with code that's already expecting only that limited set? |
A larger enumeration of codes would be insufficient to cover all the various edge cases which can trip-up web authors; it would also hinder standardization since vendors have distinct edge cases. For example, if we decide in Chrome to give a decode error when the media container (e.g., mp4) indicates that a particular video frame is a keyframe, but inspection of the coded frame indicates otherwise, we might want to emit a very specific message for this precise scenario. Having a string field gives us that flexibility to respond quickly to newly discovered edge cases. Alternatively, is there any precedent for a common registry of easily-extendable error codes that is independent of particular version of HTML5.x? I do believe we need to retain the large-granularity MediaError.code field for compatibility. |
In the past we have used the wiki for this, with moderate success. E.g. https://wiki.whatwg.org/wiki/MetaExtensions. However, I think it's not much of a burden for implementers to file an issue asking for an update to the in-spec table. I'd prefer that model; the wiki is meant more for situations where the relevant code is not necessarily shipping in browsers, which are meant to use the spec to coordinate. |
Thanks for lodging this change. We at Mozilla strongly support this. In fact we've already implemented it and is available in Firefox from version 50 (however it's only enabled on our nightly and aurora channel). So we have a "message" attribute present in the MediaError that will provide extensive description about what caused "code". The content of message itself shouldn't be subjected to a defined behaviour I believe. |
The burden of adding to the spec on every potential error log message is relatively high versus just emitting an error message verbatim in a string field. Further, these messages are likely to not have much intersection across vendors, due to media specs leaving much to quality-of-implementation. |
I see. Free-form |
Questions for you all that I encounter while speccing this:
|
SGTM. Might want to mention to web developers that the message is not standardized nor expected to be uniform across various user agent implementations.
|
Thanks, those are really helpful!
Hmm. Is it possible these error messages will reveal more details about the user than just their user agent? E.g., could they reveal the presence or absence of certain graphics card hardware, or driver versions, or similar? Should we disallow or discourage that?
Yeah, there is no impact on feature detection. I guess the question is really whether we want to require this always to contain a useful string or not. Probably we should just recommend that it do so but not require, and in that case using |
I suppose (real) decode failure on a particular piece of hardware/driver combo, but lack of such failure on other combos is already leaking information. The problem is the balance between enabling web authors to fix broken media/apps while preserving privacy. Do we have precedence here? |
SGTM |
Here is Mozilla definition: It's a plain read-only, constant DOM string. We have tests, to check on the message feature, which is simply to check if the attribute exists or not. If there's no message, the string is simply empty, just like code attribute is always set to a value.
From Mozilla approach, our changes went through our privacy and security team. They do not reveal anything about the user details, nor user agent. The file name that could be indicated in the message, is generic to mozilla build bot and do not include the full path. It is of course possible in the future that should we encountered a decoding failure due to a particular video card, that this information is showing in the message attribute. |
I think null is going to be more useful to developers than the empty string. I'm also considering the following provision:
What do you think of that? |
@ #2085 (comment), SGTM modulo: null vs "": I don't favor one over the other. |
I've put up a preliminary pull request at #2086, but I realize this is all kind of fast so I want to give this discussion a few days to settle and make sure we have participation from all relevant parties, and that we're all agreed on issues like null vs. empty string or whether we need to include any privacy guidance. We can continue discussing here; no need to move the discussion to the PR. |
Thanks for doing this. We can make message a nullable attribute if needs be. I personally don't see much of a difference between testing if an object is null or if it's empty. From the JS perspective it's really equivalent |
For what it's worth, making this nullable seems like a slightly more annoying API for authors to work with. Instead of just being able to work with the string (and check whether it's Worse yet, often enough they will forget, and only test in a UA that does have a message available, and then their code will end up throwing exceptions in another UA that uses a different media pippeline that does not provide a useful message in that situation. Then that other UA will switch to returning |
When the error is because of a network error, the message should be the empty string/null. Exposing detailed error information about network errors to JS is generally a security problem. c.f. https://html.spec.whatwg.org/#feedback-from-the-protocol:concept-websocket-closed |
That doesn't have to be. MSE allows to throw a network error at the element (via endOfStream). |
MSE itself doesn't have access to detailed network error information, right? Or do you mean that MSE should be able to populate the |
I agree that we should just use the empty string and not allow null as a value. That just results in type errors for no good reason and goes against patterns we've established elsewhere. (E.g., request.referrer returning the empty string when there's no referrer.) |
MSE endOfStream() API doesn't currently have a From feedback, it seems best that -edited to clarify 'some message parameter be' instead of just 'it' |
I still think null is a better representation of there being no message than the empty string, but I don't care strongly, so I can switch it given everyone seems to be in favor of the empty string instead. |
Per discussion, I've switched the pull request #2086 to the empty string instead of null. I've also removed "do not merge yet" since this has seen enough discussion. This still needs web platform tests though before it is ready to go. @jyavenard or @wolenetz would you be willing to write some tests for this? Is it testable without depending on UA-dependent behavior---i.e. is there a way to deterministically trigger a MediaError? |
Trying to play a 404 resource will get you a MediaError instance, but you couldn't assume anything about the message I suppose, just |
Yeah, that sounds perfect. If someone is willing to write some web platform tests for that that's all that's standing in the way of getting this merged to the spec. |
I've written w3c wpt before (MSE), but am curious - is there a distinct set of tests for whatwg? |
Nope; as stated at the top of https://github.com/w3c/web-platform-tests, "Test Suites for Web Platform specifications—including WHATWG, W3C and others". |
Excellent. I'll put something together soon. I've also sent a request for feedback [1] on this to the w3c archive and a couple MSFT HTML and MSE w3c spec editors whom I've collaborated with previously, since they might want to provide some advance input, too, but I don't believe they participate in WHATWG. [1] https://lists.w3.org/Archives/Public/www-archive/2016Nov/0004.html |
@wolenetz any progress on the web platform tests for this? :) |
Coming next week. Holidays and ramp-up are now complete :) |
Tests are looking good. Do you want to make a spec PR as well, @wolenetz? |
We already have a PR at #2086, right? (Seems you found it already.) |
Implementation bugs:
Gecko is already done: https://github.com/mozilla/gecko-dev/blob/master/dom/webidl/MediaError.webidl |
This improves the level of information available for web authors to use when debugging media playback errors. * Adds support for the MediaError.message field [1] [2] * Changes MediaLog::PipelineStatusToString() to return just a stringified version of the enum identifier, suitable for use as a UA-specific-code when included in MediaError.message. * Changes MediaLog::GetErrorMessage() to produce messages in the form: [[Stringified pipeline error code, if any, without any colon][: The first MEDIA_ERROR_LOG_ENTRY from the log, if any, since that is most likely to contain the most precise error information]] The produced message does not contain any newlines. See the updated media_browsertest.cc for basic examples. * When the message would otherwise be empty for various cases in HTMLMediaElement, and more meaningful information beyond the basic standard MediaError codes and HTMLMediaElement networkStates is available, reports basic additional information (prefixed by error code "MEDIA_ELEMENT_ERROR: ".) This should assist edge case differentiation. See the updated media_browsertest.cc for basic examples. * Test coverage: * Adds basic layout test coverage test similar to that added in [3]. * Adds basic content browser test coverage for a small variety of errors, since these messages' format and content are specific to Chrom*. The format of the message string may change in future (for example, see discussion in [4]). Also, the variety of error codes in the message prior to the first ':' will likely change in future, and the descriptive error message detail following the ':' will likely change to include more cases or more consistent format in future. [1] - whatwg/html#2085 [2] - whatwg/html#2086 [3] - web-platform-tests/wpt#4638 [4] - whatwg/html#2531 [Intent to implement and ship] - https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/yDIyWozG1xk BUG=601086, 710617 Review-Url: https://codereview.chromium.org/2660003003 Cr-Commit-Position: refs/heads/master@{#466359}
This improves the level of information available for web authors to use when debugging media playback errors. * Adds support for the MediaError.message field [1] [2] * Changes MediaLog::PipelineStatusToString() to return just a stringified version of the enum identifier, suitable for use as a UA-specific-code when included in MediaError.message. * Changes MediaLog::GetErrorMessage() to produce messages in the form: [[Stringified pipeline error code, if any, without any colon][: The first MEDIA_ERROR_LOG_ENTRY from the log, if any, since that is most likely to contain the most precise error information]] The produced message does not contain any newlines. See the updated media_browsertest.cc for basic examples. * When the message would otherwise be empty for various cases in HTMLMediaElement, and more meaningful information beyond the basic standard MediaError codes and HTMLMediaElement networkStates is available, reports basic additional information (prefixed by error code "MEDIA_ELEMENT_ERROR: ".) This should assist edge case differentiation. See the updated media_browsertest.cc for basic examples. * Test coverage: * Adds basic layout test coverage test similar to that added in [3]. * Adds basic content browser test coverage for a small variety of errors, since these messages' format and content are specific to Chrom*. The format of the message string may change in future (for example, see discussion in [4]). Also, the variety of error codes in the message prior to the first ':' will likely change in future, and the descriptive error message detail following the ':' will likely change to include more cases or more consistent format in future. [1] - whatwg/html#2085 [2] - whatwg/html#2086 [3] - web-platform-tests/wpt#4638 [4] - whatwg/html#2531 [Intent to implement and ship] - https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/yDIyWozG1xk BUG=601086, 710617 Review-Url: https://codereview.chromium.org/2660003003 Cr-Commit-Position: refs/heads/master@{#466359} (cherry picked from commit ed8e709) TBR=jochen@chromium.org,sandersd@chromium.org,mlamouri@chromium.org,mcasas@chromium.org,dalecurtis@chromium.org,foolip@chromium.org Review-Url: https://codereview.chromium.org/2837133002 . Cr-Commit-Position: refs/branch-heads/3071@{#173} Cr-Branched-From: a106f0a-refs/heads/master@{#464641}
This improves the level of information available for web authors to use when debugging media playback errors. * Adds support for the MediaError.message field [1] [2] * Changes MediaLog::PipelineStatusToString() to return just a stringified version of the enum identifier, suitable for use as a UA-specific-code when included in MediaError.message. * Changes MediaLog::GetErrorMessage() to produce messages in the form: [[Stringified pipeline error code, if any, without any colon][: The first MEDIA_ERROR_LOG_ENTRY from the log, if any, since that is most likely to contain the most precise error information]] The produced message does not contain any newlines. See the updated media_browsertest.cc for basic examples. * When the message would otherwise be empty for various cases in HTMLMediaElement, and more meaningful information beyond the basic standard MediaError codes and HTMLMediaElement networkStates is available, reports basic additional information (prefixed by error code "MEDIA_ELEMENT_ERROR: ".) This should assist edge case differentiation. See the updated media_browsertest.cc for basic examples. * Test coverage: * Adds basic layout test coverage test similar to that added in [3]. * Adds basic content browser test coverage for a small variety of errors, since these messages' format and content are specific to Chrom*. The format of the message string may change in future (for example, see discussion in [4]). Also, the variety of error codes in the message prior to the first ':' will likely change in future, and the descriptive error message detail following the ':' will likely change to include more cases or more consistent format in future. [1] - whatwg/html#2085 [2] - whatwg/html#2086 [3] - web-platform-tests/wpt#4638 [4] - whatwg/html#2531 [Intent to implement and ship] - https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/yDIyWozG1xk BUG=601086, 710617 Review-Url: https://codereview.chromium.org/2660003003 Cr-Original-Commit-Position: refs/heads/master@{#466359} Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src Cr-Mirrored-Commit: ed8e7091b5b0a51a8c0781f95813a5929c1f8110
In addition to the current "code" field, this issue requests adding a DOMString "message" field to the the
MediaError
object, which the user agent MAY populate with an informative error message.Currently, the MediaError object only allows standardized exposure of a very small enumeration of error codes (https://www.w3.org/TR/html52/semantics-embedded-content.html#error-codes).
Web authors have requested greater detail of errors, even if they are exposed in vendor-specific messages. Already, Edge has a field
msExtendedCode
. Chrome is working to add a similar, though more verbose, vendor-prefixed string field to MediaError (https://bugs.chromium.org/p/chromium/issues/detail?id=601086).Why is this needed? 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.@foolip, @jdsmith3000, @jyavenard - FYI
-- edit: s/jdsmith/jdsmith3000/
The text was updated successfully, but these errors were encountered: