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

Issue 7771 link

Starred by 77 users

Issue metadata

Status: Fixed
Owner:
User never visited
Closed: Mar 2011
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Bug

Restricted
  • Only users with Commit permission may comment.



Sign in to add a comment

Event window.onerror doesn't work

Reported by nro...@gmail.com, Feb 16 2009

Issue description

Chrome Version       : 1.0.154.8
URLs (if applicable) :
Other browsers tested:
Add OK or FAIL after other browsers where you have tested this issue:
Safari 3:
    Firefox 3: OK
         IE 7: OK

What steps will reproduce the problem?
1. Define a function to handle window errors
2. Assign this function to window.onerror event 
3. Throw new error and it never goes inside the function

What is the expected result?
The execution of the function body assigned to the window.onerror event.

What happens instead?
The error is registered into the javascript console but it never runs the 
function

Please provide any additional information below. Attach a screenshot if 
possible.

An example is attached.


 
test.html
346 bytes View Download

Comment 1 by jon@chromium.org, Feb 19 2009

Labels: -Area-Misc Area-WebKit JavaScript Mstone-2.0
Status: Assigned

Comment 2 by jon@chromium.org, Apr 3 2009

Labels: JonMoved Mstone-2.1
Moving from milestone 2 to milestone 2.1.

Comment 3 by jon@chromium.org, May 1 2009

Labels: -JonMoved Bindings
Upstream to WebKit.

Comment 4 by jon@chromium.org, May 13 2009

Labels: -Mstone-2.1 Mstone-3.0
Moving out of Mstone:2.1 as there just isn't enough time to work on this 
issue.
Labels: Report-to-webkit
Labels: mstone4
Labels: mstone-4
Labels: -mstone4
Status: Upstream
Bug filed upstream : https://bugs.webkit.org/show_bug.cgi?id=26052
Labels: -Report-to-webkit Reported-to-webkit
 Issue 17171  has been merged into this issue.

Comment 13 by karen@chromium.org, Sep 28 2009

Labels: -mstone-4 Mstone-X
i'm moving this to milestone X. i agree that it's annoying and needed but it's been in 
webkit bugs since 2006 and is still being discussed so i don't see this getting fixed by 
milestone 4. I will stay on top of the webmit bug and move it back when it's looking like 
it might be worked on.
Repro in 3.0.195.38
Would love a fix for this!
Hi, just did a test in 5.0.308.0 (37376) Ubuntu.

Reproduced error still. Tested on Firefox 3.6 as well. Attached a screenshot of testing 
in Chrome.

A fix would be much appreciated. :-) It is something we need for development of our 
current Extension.
screenshot_047.png
27.2 KB View Download
Also, should I repost this upstream at Webkit's bugzilla? Just wanted to bump them.
I also place a note on the WebKit bugzilla, this is a needed feature!
Added a note in the WebKit bugzilla, will also add it here in the hopes that a Google 
developer might tackle it there. Bottom line is that we can't recommend Chrome to 
users of our application until window.onerror is supported. We love Chrome, and fully 
support it, and since our app is listed in the Google Apps Marketplace and contains a 
number of Google API integration points, it makes little sense that we wouldn't want 
to recommend Google's browser. But window.onerror is required for our error logging 
system to work, and we rely on this to quickly detect bugs in our client code that 
have slipped through our testing. That visibility is far more important to us than 
any speed advantages Chrome might have over Firefox. 


I did the following to support error-collection: http://www.js-analytics.com
It uses the window.onerror when avaliable, but for browsers that doesn't support it
it offers a cross-browser solution using JQuery. Your welcome to try it out if it helps.

But window.onerror is important for features such as this. Firefox even supports
getting the callstack for an error, something I'd like to see in Chrome.
As javascript evolves and becomes a richer and more viable client side solution (with HTML5, V8 etc it will start to take a lot of the "heavy lifting" from Flash etc) the need for simple and elegant error trapping and reporting will grow.
Try/Catch constructs are useful but can't catch every condition and simple syntax errors either in-line or from injected (3rd party) javascript can break a page.

Without window.onerror managing the user experience becomes harder.

While the IE/Gecko solution may be a bit of a kludge it's got traction so implementing that as a base-line would be great but at the same time working on HTML5 proposals to implement a true Event/Object solution that gives both the basic script/lineno/errormessage as well as the full stack trace etc would help raise the game for the next generation.

Comment 21 by evan@chromium.org, Aug 6 2010

Status: ExternalDependency

Comment 22 by yu...@chromium.org, Aug 17 2010

Labels: -Reported-to-webkit
Status: Untriaged
@Evan/Dglaqzkov: do we know the WebKit trackerid for this (and realistically is it going to happen or will they continue to argue semantics in favor of de facto standards

I found this https://bugs.webkit.org/show_bug.cgi?id=8519 but it doesn't seem to have any real progress happening

Comment 25 by yu...@chromium.org, Aug 18 2010

Status: Assigned
I'm going to take a look into it and see what we can do there.
I see there is active work on a patch in the upstream WebKit bug. I'd like to do a security review of this once it lands, and certainly before it hits any Chromium stable release.
Ditto to all the above.  In particular we need to capture client errors so that we can be notified when a user encounters a problem.
Patch is sent upstream.  We need to come to an agreement about some implementation details with the reviewers.
awesome to see this now working in Chrome v10 on Windows (http://jsErrLog.appspot.com) but looks like it's not made it to ChromeOS on the Cr48 yet (hopefully not long, I've only tested the beta not dev channel)
Will try hitting in OSX ths week and see if it's made it there.
Safari looks like they still haven't rolled the WebKit change, and of course Opera still no news.

Comment 30 by fredsa@google.com, Mar 29 2011

The attached test case fails in Chrom 9, but works correctly in of Chrome 10

Tested in:
Google Chrome	10.0.648.204 (Official Build 79063)
WebKit	534.16 (branches/chromium/648@81505)
V8	3.0.12.30
User Agent	Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_6_6; en-US) AppleWebKit/534.16 (KHTML, like Gecko) Chrome/10.0.648.204 Safari/534.16
Command Line	 /Applications/Google Chrome.app/Contents/MacOS/Google Chrome -psn_0_19341937 --flag-switches-begin --flag-switches-end
OnErrorBug.html
965 bytes View Download

Comment 31 Deleted

Comment 32 by meer...@gmail.com, Mar 30 2011

Thanks for this - I've been waiting for this to fix an annoyance as a developer, namely the inability to see when javascript errors occur without having Developer Tools open (where breakpoints may be active etc).

So I've written a small extension that simply wraps this new feature
  https://chrome.google.com/webstore/detail/nnplccbllaclkbbmoldiamkhgohelbjh
to put a button in the toolbar that changes when javascript errors occur and offers a clearable drop down list of the errors.
Owner: a deleted user
Status: Fixed
Owner: yurys%ch...@gtempaccount.com
Revert the Owner field to yurys@chromium.org (he is claimed not to be a project member for some reason by the code site).
Project Member

Comment 35 by bugdroid1@chromium.org, Oct 13 2012

Labels: Restrict-AddIssueComment-Commit
This issue has been closed for some time. No one will pay attention to new comments.
If you are seeing this bug or have new data, please click New Issue to start a new bug.
Project Member

Comment 36 by bugdroid1@chromium.org, Mar 11 2013

Labels: -Area-WebKit Cr-Content
Project Member

Comment 37 by bugdroid1@chromium.org, Apr 6 2013

Labels: -Cr-Content Cr-Blink

Sign in to add a comment