- From: <bugzilla@jessica.w3.org>
- Date: Mon, 14 Feb 2011 22:37:33 +0000
- To: public-html-bugzilla@w3.org
http://www.w3.org/Bugs/Public/show_bug.cgi?id=12068 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 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? -- 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