This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
It seems like the main usecase for window.onerror is to act as a choke point for programming errors occurring within the page. A page could listen to all errors and report them to the server. To satisfy this usecase we're making IndexedDB error events have as default action to fire a "error" event on the window object in which the indexeddb was opened. So if the page doesn't explicitly handle the error it gets reported to the window.onerror mechanism. This makes them very similar in treatment to exceptions which is a good thing since indexeddb errors are semantically very similar to exceptions, but since they have to be asynchronous we can't use real exceptions. It was brought up that maybe we should do this with more error events. Simon Pieters put together the following list of places where we fire error events (with one addition from me): <link> <style> <script> <img> <object> <video> <source> <track> <input> ApplicationCache Worker SharedWorker EventSource WebSocket <frame> XMLHttpRequest It seems like most of these are network related. I could see an argument for reporting these to window.onerror since it's likely errors that the page author didn't expect and thus probably wants to know about. However I would also expect these to be quite common errors on existing pages, so there's a pretty big risk that making these hook into window.onerror could break existing pages. One clear exception is Worker/SharedWorker which fire error events in non-network related situations. I filed bug 12067 specifically on that so lets focus on the other ones in this bug. Are there other error events in the above list which aren't network related? Is the fact that network errors don't have a choke point a problem? If it is, would hooking them up to window.onerror be a workable solution? Or should we add a separate event specifically for unhandled network errors?
I can say WRT script elements, having `onerror` fire for other events besides network-related results would be helpful... like for instance, parsing/syntax errors. It doesn't *currently* do that, but people are definitely asking for that (as part of another WHATWG discussion list).
<video> also fires the error event for decoding errors, not just network errors.
(In reply to comment #2) > <video> also fires the error event for decoding errors, not just network > errors. <audio> and <source>, too, of course.
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: Did Not Understand Request Change Description: no spec change Rationale: This seems like a major change. I'm not fundamentally opposed to it (though I am not especially enthusiastic about having to do such extensive surgery on the spec), but I think the compatibility risks are non-trivial. I think before we do this we should try to implement it in a browser and see whether it's practical or not.
mass-move component to LC1