This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 12068 - Make window.onerror more useful
Summary: Make window.onerror more useful
Status: RESOLVED NEEDSINFO
Alias: None
Product: HTML WG
Classification: Unclassified
Component: LC1 HTML5 spec (show other bugs)
Version: unspecified
Hardware: PC All
: P2 normal
Target Milestone: ---
Assignee: Ian 'Hixie' Hickson
QA Contact: HTML WG Bugzilla archive list
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-02-14 22:37 UTC by Jonas Sicking (Not reading bugmail)
Modified: 2011-08-04 05:14 UTC (History)
7 users (show)

See Also:


Attachments

Description Jonas Sicking (Not reading bugmail) 2011-02-14 22:37:32 UTC
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?
Comment 1 Kyle Simpson 2011-02-15 02:46:22 UTC
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).
Comment 2 Philip J├Ągenstedt 2011-02-15 09:22:56 UTC
<video> also fires the error event for decoding errors, not just network errors.
Comment 3 Philip J├Ągenstedt 2011-02-15 09:23:20 UTC
(In reply to comment #2)
> <video> also fires the error event for decoding errors, not just network
> errors.

<audio> and <source>, too, of course.
Comment 4 Ian 'Hixie' Hickson 2011-05-03 19:40:41 UTC
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.
Comment 5 Michael[tm] Smith 2011-08-04 05:14:32 UTC
mass-move component to LC1