New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 147127 link

Starred by 31 users

Issue metadata

Status: Fixed
Buried. Ping if important.
Closed: Aug 2013
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Feature

Sign in to add a comment

Add an 'error' parameter to 'window.onerror' handlers, and the ErrorEvent interface.

Reported by, Sep 7 2012

Issue description

This is not actually a defect. It is a feature request, but there is no feature template available to choose from.

Me and many engineers would like the non-standard call stack available on errors in a catch block to also be available in onerror. This would help debug client errors out in the wild. It is becoming common for engineering teams to post client errors back to the server for logging and alert purposes. Having a call stack available in addition to the error message and a line and a url would be very helpful. Check out this discussion on mozilla:

Also there are lots of discussions online about wanting such a feature.
Labels: -OS-Mac -Area-Undefined -Type-Bug OS-All Area-WebKit Type-Feature Feature-DevTools
Status: Untriaged

Comment 2 by, Oct 12 2012

Status: Assigned

Comment 3 by, Oct 12 2012

Labels: -Feature-DevTools
Owner: ----
Status: Available
Project Member

Comment 4 by, Mar 10 2013

Labels: -Area-WebKit Cr-Content
Project Member

Comment 5 by, Apr 5 2013

Labels: -Cr-Content Cr-Blink

Comment 6 by, May 2 2013

See also WebKit bug on the same subject:

Comment 7 by, May 2 2013

It looks like there's already infrastructure in place to sanitize the info passed to onerror when cross-domain requires it (see  issue #159566  for example), so it seems like this should be feasible without raising any security issues.
Labels: Hotlist-GoogleApps
Any updates on this?
Labels: Cr-Platform-DevTools-JavaScript

Comment 10 by, Jul 17 2013

@komoroske: why DevTools? window.onerror is a web facing API that doesn't depend on Chromium DevTools.
Ah, I see. I didn't think about it too carefully; I was just running through a long list of issues to triage.

What do you think is a better home for this? Who would be the person or team who would actually decide to implement this? 

+arv in case he has ideas (or is the right person himself).

Comment 12 by, Jul 17 2013

Labels: -Cr-Platform-DevTools-JavaScript Cr-Blink-DOM Cr-Blink-Bindings
It's hard to say. I had a few spare cycles and supported onerror handler currently specified in HTML5 spec. Not sure who would be the right person/team to add the stack traces. I think DOM or Bindings is a more appropriate component for this feature.

Comment 13 by, Jul 17 2013

I'm interested in poking at this. I might even have some time to do so.

If we expose the same stack (with the same limitations) as we expose on the thrown error, I don't think we'd be opening any new opportunities for leakage. That said, +abarth who certainly has opinions about exposing detail like this to JavaScript.

Comment 14 Deleted

Comment 15 by, Jul 17 2013

I did a bit more digging. Mozilla seems interested in the feature[1], Apple has explicitly rejected it[2] (though there's still interest from Adobe and other in other WebKit bugs, like [3]). Before doing this, we'd probably want to a) poke blink-dev@ with an intent to implement to chat about the feature, b) poke WHATWG (to follow up on threads/concerns like [4] and [5]).

+esprehn, since he was on those threads. :)

I'm sure there's a way to do this securely.  We just need to be careful.

Comment 17 by, Jul 25 2013

Status: Assigned
Hixie has added the exception object itself as the 5th parameter, which would include the stack. That takes care of b) above, I suppose. :)

I'll follow up on a) today.

Comment 18 by, Jul 25 2013 is the change in question.

Comment 19 by, Jul 25 2013

Summary: Add an 'error' parameter to 'window.onerror' handlers, and the ErrorEvent interface. (was: Please add a call stack to onerror to help developers debug issues users are experiencing)

Comment 20 by, Jul 27 2013

 Issue 256365  has been merged into this issue.
Project Member

Comment 21 by, Aug 2 2013

The following revision refers to this bug:

r155454 | | 2013-08-02T21:51:12.899465Z

Changed paths:

Add 'error' parameter to 'window.onerror' and 'ErrorEvent'.

The HTML5 spec recently added the error object to both the
'window.onerror' callback and the 'ErrorEvent' interface in order to
improve developers' ability to debug issues that cause unexpected
exceptions in the wild[1]. This patch brings Blink's behavior into line
with that update.

Currently, we generate an ErrorEvent object after doing sanitization.
This patch refactors that code such that we generate an ErrorEvent when
V8 calls back into the bindings (V8Initializer::messageHandlerInWorker
and V8Initializer::messageHandlerInMainThread). Before we hand that
event off to core for sanitization and dispatch, we grab the wrapper
for the world in which the exception was thrown, and set the exception
object as a hidden value (V8HiddenPropertyName::error()).

On the other end, we grab that exception object in the custom 'error'
getter of 'V8ErrorEvent', and when triggering the 'onerror' handler
via 'V8ErrorHandler::callListenerFunction'. If the value exists, we're
still in the same isolated world, so we can safely return the exception
without leakage. If the value is empty, we've crossed worlds, and
return 'null' instead.

BUG= 147127 

Review URL:
Status: Fixed
Nice work! Thank you for adding this. This is going into Canary soon? 
This is in Canary now. Please bang on it and let us know what breaks. :)
This is great!  Is there a discussion around when to land this into chrome stable?
I always seem to get null no matter what. I never see the error or the stacktrace in canary. I am trying to console log it. I have :

window.onerror = function () {

setTimeout(function () {
}, 5000);

I get a null for the fifth argument.

arguments ["Script error.", "", 0, 0, null] logging.js:81
Uncaught TypeError: Object [object global] has no method 'scream' 

I looked at the tests for this change and I am not sure how to get a stack trace.
Ah looks like it was because I was loading the script from a separate domain.S ee it now!
This is awesome - the errorevent.error property works great on canary - it makes highlighting the error line possible in this example:

I'm also wondering when this will be available in chrome stable.

Sign in to add a comment