This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
while the Error event on the <video> (and <audio>) elements is useful (or will be when https://bugs.webkit.org/show_bug.cgi?id=68308 / http://code.google.com/p/chromium/issues/detail?id=96871 are resolved) the diagnostic information returned is rather limited... While there is information about the network conditions there is no easy way to determine if the request failed because the asset was not found, or the user was not authorized to access it. My suggestion would be to add support for an additional attribute on error to supplement error.code with an error.httpresponse that would give developers the ability to test and act on a 404 or 403 or 500 etc
additional clarification on suggested implementation. In the current spec when an error occurs it raises an error event and populates the MediaError code with a value (currently in the range 1..4) - http://www.whatwg.org/specs/web-apps/current-work/multipage/the-video-element.html#mediaerror what is proposed is that in addition to the MediaError (so as to maintain backwards compatibility) if the error condition is the result of an httpresponse that code is also made available. no matter when the error is raised this code should be provided (so if the asset does not exist on opening then the error.httpresponse would show a 404 but the same would happen if the asset became unavailable during the playback experience) developers may wish to take different actions based on different network conditions (a 404 or 500 response might require a different action to a 403) and this would also help (possibly) lay the groundwork for error handling in a DRM framework
This is definitely on the cards (that's why it's an object and not just a code), but I'm waiting for the browsers to implement the basic API before adding more features like this. I may mark this "LATER" at some point to help keep this separate from more urgent issues, if I do, please do not hesitate to reopen the bug if it is left that way for more than a few months. I do regularly go through all the bugs marked LATER to make sure that I deal with those whose time has come. I'm leaving this marked NEW for now because I need to investigate what UAs are doing in this area to establish how soon to address this.
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Accepted Change Description: none yet Rationale: See comment 2