Intent to implement and ship: 'window.onerror'/ErrorEvent improvements.
Mike West
Contact emails
Spec
http://www.whatwg.org/specs/web-apps/current-work/#runtime-script-errors
Summary
I'd like to make three changes to our implementation of 'window.onerror'/ErrorEvent:
1. Skip sanitization for exceptions thrown from cross-origin scripts that were served with appropriate CORS headers.
2. Add the 'column' attribute to ErrorEvent.
Motivation
Developers (especially those working on larger sites/applications) have a hard time debugging errors that happen in the wild with the tools we're currently offering to them. Many developers serve JavaScript from a CDN, which means that they get only sanitized errors in global handlers: they know an error occurred, but have no mechanism for tracking down where or why. Serving JS files with CORS headers can alleviate security/privacy concerns around data leakage, and enable better debugging possibilities. Likewise, some mechanism for obtaining stack traces would be useful: we (along with other evergreen browsers) expose a 'stack' property on exception objects. Doing the same for global event handlers (again, subject to CORS restrictions) seems like a great way of helping developers track down and fix issues.
Facebook's comments[1][2] are illustrative, and a variety of libraries have cropped up to attempt to provide the detailed, centralized error reporting functionality that we're currently failing to offer via 'window.onerror'. We should provide the functionality natively.
Compatibility Risk
#1 is low risk: WebKit[3] and Firefox[2] have already implemented the feature, we'd simply be matching their behavior.
#2 is unfortunate: IE has shipped with a property on the ErrorEvent interface named 'col'. The specification (and sanity) suggests 'column'. Christophe already landed a patch to pass the column number to the 'window.onerror' handler, but avoided doing so for the ErrorEvent interface because of this concern[4].
#3 is moderately risky: Firefox wants to add stack traces[5], there are apparently reasonable workarounds in IE[6]. While some WebKit contributors are positive on the feature[7], Apple has WONTFIXed it[8]. That said, the objections were partially standards-related: since Hixie added the 'error' bits to the spec this morning[9] after a few long threads, I'm hopeful that WebKit might come on board eventually.
Ongoing technical constraints
No.
Will this feature be supported on all five Blink platforms (Windows, Mac, Linux, Chrome OS and Android)?
Yes.
OWP launch tracking bug?
CORS support: http://crbug.com/159566
'column' parameter: http://crbug.com/264197
'error' parameter: http://crbug.com/147127
Row on feature dashboard?
No. This seems like a very small feature: I'm only sending an intent to implement because of the IE weirdness with #2, and Apple's objection to #3.
Requesting approval to ship?
Yes.
Christophe Dumez
Contact emails
Spec
http://www.whatwg.org/specs/web-apps/current-work/#runtime-script-errors
Summary
I'd like to make three changes to our implementation of 'window.onerror'/ErrorEvent:
1. Skip sanitization for exceptions thrown from cross-origin scripts that were served with appropriate CORS headers.
2. Add the 'column' attribute to ErrorEvent.
3. Add the 'error' attribute to ErrorEvent, and pass it into the 'window.onerror' handler as the 5th parameter.Motivation
Developers (especially those working on larger sites/applications) have a hard time debugging errors that happen in the wild with the tools we're currently offering to them. Many developers serve JavaScript from a CDN, which means that they get only sanitized errors in global handlers: they know an error occurred, but have no mechanism for tracking down where or why. Serving JS files with CORS headers can alleviate security/privacy concerns around data leakage, and enable better debugging possibilities. Likewise, some mechanism for obtaining stack traces would be useful: we (along with other evergreen browsers) expose a 'stack' property on exception objects. Doing the same for global event handlers (again, subject to CORS restrictions) seems like a great way of helping developers track down and fix issues.
Facebook's comments[1][2] are illustrative, and a variety of libraries have cropped up to attempt to provide the detailed, centralized error reporting functionality that we're currently failing to offer via 'window.onerror'. We should provide the functionality natively.
Compatibility Risk
#1 is low risk: WebKit[3] and Firefox[2] have already implemented the feature, we'd simply be matching their behavior.
#2 is unfortunate: IE has shipped with a property on the ErrorEvent interface named 'col'. The specification (and sanity) suggests 'column'. Christophe already landed a patch to pass the column number to the 'window.onerror' handler, but avoided doing so for the ErrorEvent interface because of this concern[4].
Christophe DUMEZ
Michael Davidson
3. Add the 'error' attribute to ErrorEvent, and pass it into the 'window.onerror' handler as the 5th parameter.
PhistucK
Erik Arvidsson
Is there any chance we can change the property names to be consistent?
erik
Christophe Dumez
On Thursday 25 July 2013 at 22:06, Erik Arvidsson wrote:
LGTMIs there any chance we can change the property names to be consistent?
Christophe Dumez
Dimitri Glazkov
Adam Barth
Good news, ‘column’ was just renamed to ‘colno’ in the specification to match IE10:
