W3C home > Mailing lists > Public > public-html-bugzilla@w3.org > February 2011

[Bug 12068] New: Make window.onerror more useful

From: <bugzilla@jessica.w3.org>
Date: Mon, 14 Feb 2011 22:37:33 +0000
To: public-html-bugzilla@w3.org
Message-ID: <bug-12068-2486@http.www.w3.org/Bugs/Public/>

           Summary: Make window.onerror more useful
           Product: HTML WG
           Version: unspecified
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: HTML5 spec (editor: Ian Hickson)
        AssignedTo: ian@hixie.ch
        ReportedBy: jonas@sicking.cc
         QAContact: public-html-bugzilla@w3.org
                CC: mike@w3.org, public-html-wg-issue-tracking@w3.org,
                    public-html@w3.org, simonp@opera.com

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

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):


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?

Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
Received on Monday, 14 February 2011 22:37:35 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:01:41 UTC