Last Comment Bug 503244 - Log exceptions thrown from event listener callbacks in the error console
: Log exceptions thrown from event listener callbacks in the error console
Status: RESOLVED FIXED
: regression
Product: Core
Classification: Components
Component: DOM (show other bugs)
: Trunk
: x86 Windows 7
: -- normal with 15 votes (vote)
: mozilla27
Assigned To: Boris Zbarsky [:bz]
:
Mentors:
: 377347 574941 631125 649799 697300 851765 896928 (view as bug list)
Depends on: 835643 862627
Blocks: 908954 455436 895548
  Show dependency treegraph
 
Reported: 2009-07-08 21:29 PDT by alfredkaseltzer
Modified: 2013-09-25 14:06 PDT (History)
42 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
no error logged in 3.5 (582 bytes, text/html)
2009-07-08 21:31 PDT, alfredkaseltzer
no flags Details
reduced failing test case (361 bytes, text/html)
2009-08-10 10:33 PDT, Tobie Langel
no flags Details
Set aside JS frame stack when calling DispatchEvent on an event listener to avoid swallowing exceptions unintentionally. (3.15 KB, patch)
2011-10-26 15:34 PDT, Josh Matthews [:jdm]
no flags Details | Diff | Splinter Review
Set aside JS frame stack when calling DispatchEvent on an event listener to avoid swallowing exceptions unintentionally. (1.55 KB, patch)
2011-10-26 15:41 PDT, Josh Matthews [:jdm]
no flags Details | Diff | Splinter Review

Description alfredkaseltzer 2009-07-08 21:29:27 PDT
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2a1pre) Gecko/20090708 Minefield/3.6a1pre (.NET CLR 3.5.30729)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2a1pre) Gecko/20090708 Minefield/3.6a1pre (.NET CLR 3.5.30729)

Any errors thrown from an event handler called via a simulated event will not show up in the Error Console.


Reproducible: Always

Steps to Reproduce:
1.Create a javascript function that throws an event.
2.Call that function via a simulated event (createEvent,initEvent,dispatchEvent for example)
Actual Results:  
The error thrown doesn't appear in the Error Console.

Expected Results:  
Displayed exception information in the Error Console.

I've attached a some code that illustrates this.

In previous versions, the following error would be logged when opening this page:

Error: [Exception... "'Error: error' when calling method: [nsIDOMEventListener::handleEvent]"  nsresult: "0x8057001c (NS_ERROR_XPC_JS_THREW_JS_OBJECT)"  location: "JS frame :: http://7e2617e61ec94e3/wiggles/home/default.html :: <TOP_LEVEL> :: line 15"  data: no]
Source File: http://example.com/
Line: 15

I've been able to reproduce this on XP SP3 and Windows 7 RC1 (build 7100).
Comment 1 alfredkaseltzer 2009-07-08 21:31:28 PDT
Created attachment 387595 [details]
no error logged in 3.5
Comment 2 Tobie Langel 2009-08-10 10:31:26 PDT
Was able to reproduce on Firefox 3.5.2 on Mac OS 10.5.7 with the following code: http://gist.github.com/165294
Comment 3 Tobie Langel 2009-08-10 10:33:48 PDT
Created attachment 393539 [details]
reduced failing test case

This HTML file should throw an error when opened in a browser. Doesn't in FF 3.5.2.
Comment 4 u88484 2009-08-10 10:48:52 PDT
Tobie, can you reproduce this in Firefox's safe mode?  Also, how about if you toggle jit.chrome to false in about:config?
Comment 5 Tobie Langel 2009-08-10 11:04:18 PDT
Yes, reproduced it in safe mode with jit.chrome both set to false (default on my install, FWIW) and to true.
Comment 6 u88484 2009-08-10 11:08:54 PDT
Ok thanks!  This this regress in the 3.5 release?  Like it worked in Firefox 3.0.X but not in 3.5.X?
Comment 7 Tobie Langel 2009-08-10 11:10:06 PDT
Correct.
Comment 8 Tobie Langel 2009-08-10 11:15:29 PDT
I confirm it's a regression. In 3.0.13 safe mode, test page correctly throws:

Error: [Exception... "'resized!' when calling method: [nsIDOMEventListener::handleEvent]"  nsresult: "0x8057001e (NS_ERROR_XPC_JS_THREW_STRING)"  location: "JS frame :: file:///Users/tobie/Desktop/test.html :: <TOP_LEVEL> :: line 8"  data: no]
Source File: file:///Users/tobie/Desktop/test.html
Line: 8
Comment 9 Myers Carpenter 2011-04-13 14:22:51 PDT
*** Bug 649799 has been marked as a duplicate of this bug. ***
Comment 10 Josh Matthews [:jdm] 2011-04-14 08:17:57 PDT
*** Bug 574941 has been marked as a duplicate of this bug. ***
Comment 11 Josh Matthews [:jdm] 2011-04-14 09:28:52 PDT
Using the testcase from bug 574941, I found that the stack looks like this, as one would expect:

#0  js::Interpret (cx=0x9912750, entryFrame=0xb39fe0a0, inlineCallCount=0, interpMode=JSINTERP_NORMAL) at /home/t_mattjo/src/firefox/mozilla-central/js/src/jsinterp.cpp:6191
#1  0x02604dec in js::RunScript (cx=0x9912750, script=0x9ef6140, fp=0xb39fe0a0) at /home/t_mattjo/src/firefox/mozilla-central/js/src/jsinterp.cpp:653
#2  0x026052eb in js::Invoke (cx=0x9912750, argsRef=..., flags=8192) at /home/t_mattjo/src/firefox/mozilla-central/js/src/jsinterp.cpp:740
#3  0x026058cb in js::ExternalInvoke (cx=0x9912750, thisv=..., fval=..., argc=1, argv=0xbfb6c718, rval=0xbfb6c790) at /home/t_mattjo/src/firefox/mozilla-central/js/src/jsinterp.cpp:863
#4  0x02569a9e in JS_CallFunctionValue (cx=0x9912750, obj=0xb253f8f8 [Object HTMLDocument], fval=$jsval(0xb253f038 [Object Function <unnamed>]), argc=1, argv=0xbfb6c718, rval=0xbfb6c790)
    at /home/t_mattjo/src/firefox/mozilla-central/js/src/jsapi.cpp:5173
#5  0x01a324a8 in nsXPCWrappedJSClass::CallMethod (this=0x942b110, wrapper=0x965fa00, methodIndex=3, info=0x8fba708, nativeParams=0xbfb6ca6c)
    at /home/t_mattjo/src/firefox/mozilla-central/js/src/xpconnect/src/xpcwrappedjsclass.cpp:1672
#6  0x01a29307 in nsXPCWrappedJS::CallMethod (this=0x965fa00, methodIndex=3, info=0x8fba708, params=0xbfb6ca6c) at /home/t_mattjo/src/firefox/mozilla-central/js/src/xpconnect/src/xpcwrappedjs.cpp:588
#7  0x021ae5db in PrepareAndDispatch (methodIndex=3, self=0x9da5c20, args=0xbfb6cb44) at /home/t_mattjo/src/firefox/mozilla-central/xpcom/reflect/xptcall/src/md/unix/xptcstubs_gcc_x86_unix.cpp:95
#8  0x01302906 in nsEventListenerManager::HandleEventSubType (this=0x9f1ba88, aListenerStruct=0x9b68ef0, aListener=0x9da5c20, aDOMEvent=0x92bf378, aCurrentTarget=0x911d3b0, aPhaseFlags=2, aPusher=0xbfb6ce48)
    at /home/t_mattjo/src/firefox/mozilla-central/content/events/src/nsEventListenerManager.cpp:1127
#9  0x01302cee in nsEventListenerManager::HandleEventInternal (this=0x9f1ba88, aPresContext=0x9ce4dd0, aEvent=0x92fe558, aDOMEvent=0xbfb6ce60, aCurrentTarget=0x911d3b0, aFlags=2, aEventStatus=0xbfb6ce64, aPusher=
    0xbfb6ce48) at /home/t_mattjo/src/firefox/mozilla-central/content/events/src/nsEventListenerManager.cpp:1222
#10 0x0132d0d8 in nsEventListenerManager::HandleEvent (this=0x9f1ba88, aPresContext=0x9ce4dd0, aEvent=0x92fe558, aDOMEvent=0xbfb6ce60, aCurrentTarget=0x911d3b0, aFlags=2, aEventStatus=0xbfb6ce64, aPusher=0xbfb6ce48)
    at /home/t_mattjo/src/firefox/mozilla-central/content/events/src/nsEventListenerManager.h:146
#11 0x0132d59a in nsEventTargetChainItem::HandleEvent (this=0x9432c08, aVisitor=..., aFlags=2, aMayHaveNewListenerManagers=0, aPusher=0xbfb6ce48)
    at /home/t_mattjo/src/firefox/mozilla-central/content/events/src/nsEventDispatcher.cpp:212
#12 0x0132b394 in nsEventTargetChainItem::HandleEventTargetChain (this=0x9432aa8, aVisitor=..., aFlags=6, aCallback=0x0, aMayHaveNewListenerManagers=0, aPusher=0xbfb6ce48)
    at /home/t_mattjo/src/firefox/mozilla-central/content/events/src/nsEventDispatcher.cpp:364
#13 0x0132bf23 in nsEventDispatcher::Dispatch (aTarget=0x94eb298, aPresContext=0x9ce4dd0, aEvent=0x92fe558, aDOMEvent=0x92bf378, aEventStatus=0xbfb6cf94, aCallback=0x0, aTargets=0x0)
    at /home/t_mattjo/src/firefox/mozilla-central/content/events/src/nsEventDispatcher.cpp:628
#14 0x0132c2d6 in nsEventDispatcher::DispatchDOMEvent (aTarget=0x94eb298, aEvent=0x0, aDOMEvent=0x92bf378, aPresContext=0x9ce4dd0, aEventStatus=0xbfb6cf94)
    at /home/t_mattjo/src/firefox/mozilla-central/content/events/src/nsEventDispatcher.cpp:691
#15 0x013031e6 in nsEventListenerManager::DispatchEvent (this=0x93b06b0, aEvent=0x92bf378, _retval=0xbfb6d024) at /home/t_mattjo/src/firefox/mozilla-central/content/events/src/nsEventListenerManager.cpp:1345
#16 0x01235a91 in nsDOMEventRTTearoff::DispatchEvent (this=0x9ec44b8, aEvt=0x92bf378, _retval=0xbfb6d024) at /home/t_mattjo/src/firefox/mozilla-central/content/base/src/nsGenericElement.cpp:2040
#17 0x01a89df9 in nsIDOMEventTarget_DispatchEvent (cx=0x9912750, argc=1, vp=0xb39fe060) at dom_quickstubs.cpp:13959
#18 0x02608c24 in js::CallJSNative (cx=0x9912750, native=0x1a89c89 <nsIDOMEventTarget_DispatchEvent(JSContext*, uintN, jsval*)>, argc=1, vp=0xb39fe060)
    at /home/t_mattjo/src/firefox/mozilla-central/js/src/jscntxtinlines.h:701
#19 0x0283b994 in js::Interpret (cx=0x9912750, entryFrame=0xb39fe030, inlineCallCount=0, interpMode=JSINTERP_NORMAL) at /home/t_mattjo/src/firefox/mozilla-central/js/src/jsinterp.cpp:4799
#20 0x02604dec in js::RunScript (cx=0x9912750, script=0x92eded8, fp=0xb39fe030) at /home/t_mattjo/src/firefox/mozilla-central/js/src/jsinterp.cpp:653
#21 0x026060f7 in js::Execute (cx=0x9912750, chain=0xb253d280 [Object Window], script=0x92eded8, prev=0x0, flags=0, result=0x0) at /home/t_mattjo/src/firefox/mozilla-central/js/src/jsinterp.cpp:1028
#22 0x02569180 in EvaluateUCScriptForPrincipalsCommon (cx=0x9912750, obj=0xb253d280 [Object Window], principals=0x9d5f774, chars=0x9c3f778, length=232, filename=
    0x9c5c178 "https://bug503244.bugzilla.mozilla.org/attachment.cgi?id=393539", lineno=4, rval=0x0, compileVersion=JSVERSION_DEFAULT) at /home/t_mattjo/src/firefox/mozilla-central/js/src/jsapi.cpp:5059
#23 0x0256922b in JS_EvaluateUCScriptForPrincipalsVersion (cx=0x9912750, obj=0xb253d280 [Object Window], principals=0x9d5f774, chars=0x9c3f778, length=232, filename=
    0x9c5c178 "https://bug503244.bugzilla.mozilla.org/attachment.cgi?id=393539", lineno=4, rval=0x0, version=JSVERSION_DEFAULT) at /home/t_mattjo/src/firefox/mozilla-central/js/src/jsapi.cpp:5075
#24 0x014fb13e in nsJSContext::EvaluateString (this=0x9912708, aScript=..., aScopeObject=0xb253d280, aPrincipal=0x9d5f770, aURL=0x9c5c178 "https://bug503244.bugzilla.mozilla.org/attachment.cgi?id=393539", aLineNo=4, 
    aVersion=0, aRetValue=0x0, aIsUndefined=0xbfb6e3f8) at /home/t_mattjo/src/firefox/mozilla-central/dom/base/nsJSEnvironment.cpp:1460
#25 0x01275fdd in nsScriptLoader::EvaluateScript (this=0x9129bf0, aRequest=0x9f219a0, aScript=...) at /home/t_mattjo/src/firefox/mozilla-central/content/base/src/nsScriptLoader.cpp:906

where the top frame is the throw instruction.

In nsXPCWrappedJSClass::CallMethod we correctly determine that the event handler was unsuccessful, and call

>        return CheckForException(ccx, name, GetInterfaceName(), forceReport);

In CheckForException, we determine it's a JS exception and attempt to report it:

>            if(reportable && is_js_exception &&
>               cx->errorReporter != xpcWrappedJSErrorReporter)
>            {
>                reportable = !JS_ReportPendingException(cx);
>            }

This correctly ends up in NS_ScriptErrorReporter, but then we discover that there is another JS stack frame, so we don't bother reporting.  Back in nsXPCWrappedJSClass::CheckForException, we save the exception on the XPC context:

>            // Whether or not it passes the 'reportable' test, it might
>            // still be an error and we have to do the right thing here...
>            if(NS_FAILED(e_result))
>            {
>                ccx.GetThreadData()->SetException(xpc_exception);
>                return e_result;
>            }

and then clear the pending exception on cx because there's and AutoClearPendingException object on the stack.

I'm not really sure who calls GetThreadData)->GetException in the codebase, but there's no other XPConnect machinery in the original call stack, and the cx's pending exception has been cleared, so it doesn't surprise me very much that we lose the exception here.  Thoughts, those in the know?
Comment 12 Myers Carpenter 2011-04-26 05:15:00 PDT
I would like to underscore how painful this bug is.  The company I work for has a large Javascript based application based on Prototype.js.  Much of the code is triggered around firing events via dispatchEvent.  With errors not being reported our suite of Unit tests are failing with no notice.  To debug error we have to add try/catch blocks all over the handlers to try to see if there is a problem.
Comment 13 Olli Pettay [:smaug] 2011-04-26 06:23:00 PDT
Regression range would be very useful.
Comment 14 JB Hurteaux 2011-05-25 00:06:34 PDT
This is also a blocker here and I quite fail to understand how it does not impact more people.
Are there no regression test tools based on the possibility to simulate event handlers? How are they not impacted by this?
Comment 15 radsaq 2011-05-25 08:35:03 PDT
After a failed attempt to try to compile mozilla-central from 2008 (thus preventing me from doing an hg bisect), I started going through old nightly builds.

This works: http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2008/09/2008-09-26-02-mozilla-central/

Unfortunately, no builds after that until http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2008/11/2008-11-07-01-mozilla-central/ will start up for me, which shows the bug.

I guess that just narrows the regression down to being introduced in 3.1b2. Does that help?
Comment 16 radsaq 2011-05-25 09:09:31 PDT
Okay, I discovered that the win32 nightly builds from October 2008 actually start up, so I did a bit more digging.

Works: http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2008/10/2008-10-12-03-mozilla-central/
Does not work: http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2008/10/2008-10-13-03-mozilla-central/

Not much changed on the 12th. Could it have been http://hg.mozilla.org/mozilla-central/rev/46edde157751 ?
Comment 17 Olli Pettay [:smaug] 2011-05-25 09:15:20 PDT
Could you look at the changesets of those builds and
give a link to the regression range.
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=<changeset1>&tochange=<changeset2>
Comment 18 Olli Pettay [:smaug] 2011-05-25 09:15:51 PDT
You can get the changeset from about:buildconfig
Comment 20 Olli Pettay [:smaug] 2011-05-25 09:26:54 PDT
http://hg.mozilla.org/mozilla-central/rev/3aec0eec68a1 looks suspicious
Comment 21 Josh Matthews [:jdm] 2011-05-25 10:48:06 PDT
Olli, given that bug 455436 introduced the code in NS_ScriptErrorReporter that short-circuits if a previous JS stack frame is found, I think it's safe to say that it caused the change in behaviour here.
Comment 22 Josh Matthews [:jdm] 2011-05-25 11:07:43 PDT
I suspect the correct fix here (and possibly bug 502718 as well) will be along the lines of what bug 489671 did - when the event handler is triggered, we want to pretend that no previous JS frames exist. Boris, any thoughts? Presumably, the main thing causing the fix for bug 489671 not to work is that nsXPCWrappedJSClass::CheckForException clears the pending exception, so the later machinery can't do anything about it.
Comment 23 Josh Matthews [:jdm] 2011-05-25 11:08:25 PDT
Whoops, forgot to cc bz when directly addressing him in comment 22.
Comment 24 Boris Zbarsky [:bz] 2011-05-25 11:31:44 PDT
That seems like the obvious fix here, yes.  I suspect that the real issue is that we're not going through nsJSContext::CallEventHandler at all in this case, so we're not hitting the code that I changed in bug 489671.

Can we just set aside the frame chain in the event listener manager before calling handleEvent on the listener?
Comment 25 Josh Matthews [:jdm] 2011-05-25 11:41:56 PDT
I'll look into that potential solution.
Comment 26 Olli Pettay [:smaug] 2011-05-25 14:55:36 PDT
Huh, to add some new JS API stuff to ELM. Please no. XPConnect should be
wise enough to do such things.
But if hacking ELM is the only solution, be *very* careful with performance.
Everything under nsEventListenerManager::HandleEventInternal shows up in the
performance profiles. (There are anyway still things to optimize, but I
certainly don't want to make things slower.)
Comment 27 Boris Zbarsky [:bz] 2011-05-25 18:25:26 PDT
Well.  ELM is already manually pushing nsJSContexts, right?  We can just make whatever it does there also set aside the frame chain.
Comment 28 Olli Pettay [:smaug] 2011-05-26 03:03:28 PDT
Well, ELM just relies on nsCxPusher to do the right thing when
nsPIDOMEventTarget is passed as a parameter. And we're trying to get rid of that
cx pushing anyway.

How fast or slow is  it to set aside the frame chain?
Comment 29 Boris Zbarsky [:bz] 2011-05-26 07:56:26 PDT
Good question.  It used to be just a bit of pointer-twiddling, but at this point it looks like it might be doing something with the stack.  Luke?
Comment 30 Luke Wagner [:luke] 2011-05-26 11:00:30 PDT
You're right Boris.

Incidentally, I was just looking at the JS_SaveFrameChain usage for a different reason and wondering if there could not be a better, less-hacky solution to this errors-getting-eaten problem.  I admit I don't really understand all the constraints at play here for NS_ScriptErrorReporter; I'm just wishfully asking since one day I'd like to remove JS_SaveFrameChain in lieu changes to the JSAPI to make continuing/breaking current call chain explicit at the call site.
Comment 31 Josh Matthews [:jdm] 2011-05-29 21:28:06 PDT
I've got a patch which makes the error show up. I've pushed to try at http://tbpl.mozilla.org/?tree=Try&rev=cbb29a306532
Comment 32 Josh Matthews [:jdm] 2011-05-30 00:02:05 PDT
So far the patch seems to have busted test_bug390488.html and test_bug549170.html, but I can't reproduce the second one locally. The first breakage is obvious - since we now chop any frames before the event handler, we no longer see the simulateClick caller in the stack. Is this the intended/desired behaviour?
Comment 33 Olli Pettay [:smaug] 2011-05-30 03:00:39 PDT
The moved QI call in the patch will certainly show up in the profiles
(but perhaps that is just a leftover since there is anyway some 
commented-out code).
Also, doesn't nsContentUtils::GetCurrentJSContext return just the same
context we pushed in the HandleEventInternal?
Could we do something faster?

http://mozilla.pettay.fi/moztests/events/event_speed_3.html
could work for profiling this case.

About bug 390488, what do other browsers do?
Comment 34 Josh Matthews [:jdm] 2011-05-31 07:34:40 PDT
Google Chrome 6-13 shows simulateClick, onClick, anonymous, checkForStacks.
Comment 35 JB Hurteaux 2011-10-05 08:26:12 PDT
Trying to stir the pot.

It seems we were close to a fix then all activity died on this bug.
Comment 36 Josh Matthews [:jdm] 2011-10-26 15:32:27 PDT
*** Bug 697300 has been marked as a duplicate of this bug. ***
Comment 37 Josh Matthews [:jdm] 2011-10-26 15:34:53 PDT
Created attachment 569822 [details] [diff] [review]
Set aside JS frame stack when calling DispatchEvent on an event listener to avoid swallowing exceptions unintentionally.

Attaching a WIP so that I don't lose all my work if I start ignoring this bug for another five months.
Comment 38 Josh Matthews [:jdm] 2011-10-26 15:38:13 PDT
*** Bug 377347 has been marked as a duplicate of this bug. ***
Comment 39 Olli Pettay [:smaug] 2011-10-26 15:39:18 PDT
I need to run my perf tests with and without the patch. 
I would be surprised if this doesn't slow down event handling.
Comment 40 Olli Pettay [:smaug] 2011-10-26 15:40:38 PDT
Also, is this the right level to do this stuff. What about other
interfaces with [function]? Do they have the same problem?
Comment 41 Josh Matthews [:jdm] 2011-10-26 15:41:27 PDT
Created attachment 569825 [details] [diff] [review]
Set aside JS frame stack when calling DispatchEvent on an event listener to avoid swallowing exceptions unintentionally.
Comment 42 Josh Matthews [:jdm] 2011-10-26 16:06:41 PDT
Results for http://mozilla.pettay.fi/moztests/events/event_speed_3.html:

without patch: avg of 30 results (total tests 50) : 3569ms
with patch: avg of 30 results (total tests 50) : 3643.6666666666665ms
Comment 43 Josh Matthews [:jdm] 2011-10-26 16:08:23 PDT
Note, the tests in comment 42 were from rev cc66accc8181 and using depth 100.
Comment 44 Mozilla RelEng Bot 2011-10-26 23:20:31 PDT
Try run for bd51b9bf9001 is complete.
Detailed breakdown of the results available here:
    https://tbpl.mozilla.org/?tree=Try&rev=bd51b9bf9001
Results (out of 256 total builds):
    success: 195
    warnings: 61
Builds available at http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/josh@joshmatthews.net-bd51b9bf9001
Comment 45 Olli Pettay [:smaug] 2011-10-27 03:49:53 PDT
>3500ms? Were you using a debug  build? I get something like 300ms without the patch on this machine.

And also, do we have the same problem with other [function] interfaces? If so, the
code should go to XPconnect.
Comment 46 Sebastian Zartner 2011-12-28 15:40:51 PST
There's a related Firebug issue:
http://code.google.com/p/fbug/issues/detail?id=3016

Sebastian
Comment 47 Sebastian Zartner [:sebo] 2012-08-15 23:58:38 PDT
We just had another request:
http://code.google.com/p/fbug/issues/detail?id=5818

All other major browsers throw the error in this case.

Sebastian
Comment 48 Olli Pettay [:smaug] 2012-10-01 08:59:29 PDT
bholley, could we handle this somewhere in xpconnect level?
This certainly doesn't belong to ELM, since we have plenty of other callbacks too.
Comment 49 Bobby Holley (:bholley) (busy with Stylo) 2012-10-01 14:31:30 PDT
(In reply to Olli Pettay [:smaug] from comment #48)
> bholley, could we handle this somewhere in xpconnect level?
> This certainly doesn't belong to ELM, since we have plenty of other
> callbacks too.

I don't grok the issue here well enough to answer without digging. Maybe jdm has a better sense?
Comment 50 Josh Matthews [:jdm] 2012-10-01 14:49:02 PDT
It's always _felt_ like something we should be handling at the xpconnect level whenever I've stepped through the code and watched it reset the exception data, but I really can't give any better insight than that.
Comment 51 Mihai Sucan [:msucan] 2013-03-28 09:54:42 PDT
*** Bug 851765 has been marked as a duplicate of this bug. ***
Comment 52 Boris Zbarsky [:bz] 2013-05-31 09:37:31 PDT
*** Bug 631125 has been marked as a duplicate of this bug. ***
Comment 53 :Gijs Kruitbosch (Gone July 28 - Aug 11) 2013-07-03 01:47:47 PDT
jdm, are you still working on this and/or what needs to happen to move this forward? :-)
Comment 54 Josh Matthews [:jdm] 2013-07-03 04:50:08 PDT
We're going to get this for free with bug 862627. There's no real point in attacking it until that happens, in my opinion.
Comment 55 Boris Zbarsky [:bz] 2013-07-03 08:12:57 PDT
What needs to happen to move this along is fixing our window teardown insanity so I can land bug 862627, at which point this will Just Work.
Comment 56 David Bruant 2013-07-09 16:17:47 PDT
Just FYI, I've been working on an addon that shows the stack trace in the console recently. Code at https://github.com/DavidBruant/usefulStackTrace
I've worked the last couple of days to get a stack trace for the test case of this bug. My issue wasn't so much about DOM code than it was about catching an error before DOMContentLoaded...
Anyway. Get the code, follow the instructions in the readme and you should be able to enjoy error messages and stack traces even if the error was thrown from an event handler.

This addon has a lot of room for improvement (submitting to a.m.o would be a start :-/), but at least, no error will be missing if you have it enabled with the webconsole open. The addon works in Firefox 24+ (should work in Firefox 23).
Comment 57 Boris Zbarsky [:bz] 2013-07-23 07:16:34 PDT
*** Bug 896928 has been marked as a duplicate of this bug. ***
Comment 58 Boris Zbarsky [:bz] 2013-09-23 17:58:33 PDT
Fixed by bug 862627.
Comment 59 Sebastian Zartner [:sebo] 2013-09-25 13:44:08 PDT
Works for me, thanks!

Sebastian
Comment 60 David Humphrey (:humph) 2013-09-25 14:06:46 PDT
woo!  Great fix, this is wonderful to see.

Note You need to log in before you can comment on or make changes to this bug.