This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
The HTML5 specification only covers the onerror handler, and it says: [quote] Whenever an uncaught runtime script error occurs in one of the scripts associated with a Document, the user agent must report the error at the URL of the resource containing the script (as established when the script was created), with the problematic position (line number and column number) in that resource, in the script's origin, using the onerror event handler of the script's global object. If the error is still not handled after this, then the error may be reported to the user. [/quote] The web workers specification introduces the ErrorEvent interface so that web worker errors can be as rich as normal page errors. This bug makes it clear this was the intention: https://www.w3.org/Bugs/Public/show_bug.cgi?id=18289 The DOM Level 2 Events specification never covered addEventListener("error", ...) at all, but the DOM Level 3 Events specification finally does, and it says: Interface: UIEvent if generated from a user interface, Event otherwise. This has the effect that: * Page errors caught with onerror: Rich Error Information * Page errors caught with addEventListener: *No Error Information* * Worker errors caught with onerror: Rich Error Information * Worker errors caught with addEventListener: Rich Error Information So we have an odd man out. Testing with most browser shows that they return the richer ErrorEvent interface anyway, whereas Firefox currently does not. Someone at Firefox suggested I raised a spec bug to help with this.
(In reply to comment #0) > * Page errors caught with onerror: Rich Error Information > * Page errors caught with addEventListener: *No Error Information* > * Worker errors caught with onerror: Rich Error Information > * Worker errors caught with addEventListener: Rich Error Information > > So we have an odd man out. Testing with most browser shows that they return the > richer ErrorEvent interface anyway, WebKit does, but Opera follows the spec and does not fire any 'error' event at all for page errors. Firefox fires an event with the Event interface. I don't know what IE does. > whereas Firefox currently does not. Someone > at Firefox suggested I raised a spec bug to help with this. If we start firing an event, how do we make onerror *not* be invoked for that event? (onerror needs to be invoked directly with three arguments instead of using the event mechanism, but it still needs to function as an event listener, too.) Is there Web content expecting addEventListener('error', ...) to work?
(In reply to comment #0) > > The DOM Level 2 Events specification never covered addEventListener("error", > ...) at all, but the DOM Level 3 Events specification finally does, and it > says: > > Interface: UIEvent if generated from a user interface, Event otherwise. This is bogus; only the specification that actually fires the event can say what the event's interface object is. You should ignore the DOM Level 3 Events spec, it is wrong. > This has the effect that: > > * Page errors caught with onerror: Rich Error Information > * Page errors caught with addEventListener: *No Error Information* > * Worker errors caught with onerror: Rich Error Information > * Worker errors caught with addEventListener: Rich Error Information No, this is wrong. All the 'error' _events_ are the same, whether caught by onerror or addEventListener or any other mechanism (e.g. XML Events, XBL2 handlers, etc). The only reason onerror is special here is that sometimes no event is fired at all, it's treated as a separate callback for error handling. However, this has nothing to do with ErrorEvent or addEventListener. It's just the "report the error" logic.