On non-worker errors, the spec calls window.onerror directly without firing an "error" ErrorEvent, so listeners for the "error" event aren't called.  This doesn't match browsers.

Chrome fires error events with an ErrorEvent; the message, filename and lineno fields are set.
IE10 fires error events with an Error; the message, filename and lineno fields are set, so this is just an ErrorEvent without the interface.
Firefox fires error events with an Error.  The error fields aren't populated in this browser.
Opera is the only browser that doesn't fire the error event at all.

I'd recommend simply firing an error event normally, with an ErrorEvent object, and let window.onerror be called like any other event handler.  The special case of onerror's arguments (msg, file, line rather than the event object) should be handled at the place event handlers are invoked.

This would also mean that firing an error event manually with dispatchEvent would call window.onerror with the special arguments instead of the event.  That seems correct, so user error events work.  Currently, it's hard or impossible to do this in script (eg. catch an exception and fire it as an error event).

Chrome (other WebKits untested) implements this already: http://zewt.org/~glenn/test-error-handler.html.  It only happens if the event is an ErrorEvent.  This change should also be compatible with IE10 and Firefox, simply because there seems to be no way to get an ErrorEvent in the UI thread on those browsers in the first place, so there's no code to break.  (IE10 has ErrorEvent but constructing it doesn't work.  Firefox doesn't appear to have ErrorEvent yet.)