Moving from milestone 2 to milestone 2.1.

Upstream to WebKit.

Moving out of Mstone:2.1 as there just isn't enough time to work on this 
issue.

Bug filed upstream : https://bugs.webkit.org/show_bug.cgi?id=26052

this is now
https://bugs.webkit.org/show_bug.cgi?id=8519

Issue 17171 has been merged into this issue.

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.

@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

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.

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

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.

Revert the Owner field to yurys@chromium.org (he is claimed not to be a project member for some reason by the code site).

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.