Closed Bug 312448 Opened 19 years ago Closed 13 years ago

|throw| in an event handler attached with addEventListener does not cause onerror function to be called

Categories

(Core :: XPConnect, defect)

defect
Not set
normal

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: mongena, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: testcase)

Attachments

(2 files)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 Firefox/1.0.7
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 Firefox/1.0.7

When you add an eventhandler to a html element (e.g. input box) using the
addEventListener method and in this event handler you throw an error firefox
doesn't throw the error but seems to do nothing.  In the Javascript console you
get an error:
Error: [Exception... "'Error: error' when calling method:
[nsIDOMEventListener::handleEvent]"  nsresult: "0x8057001c
(NS_ERROR_XPC_JS_THREW_JS_OBJECT)"  location: "<unknown>"  data: no]

Reproducible: Always

Steps to Reproduce:
1.Create a simple input element in you html code (name it testinput)
2.Create a button which calls a testerror function when clicked
3.Add an eventhandler to the onchange event of the input element using these lines
var input = document.getElementById("testInput");
addEventListener(input, "change", InputChanged); 
4. Create your eventhandler which throws an error
function InputChanged() {
    throw new Error("error");
}
5. use window.onerror
window.onerror = handleError;
6. write your handleError method
function handleError(sMsg, sUrl, sLine) {
    alert(sMsg);
}
7. open your page in Firefox
8. click the button
9. change the content of your edit box
10. press tab


Actual Results:  
Nothing seems to happen.
You get an error message in the Javascript Console
Error: [Exception... "'Error: error' when calling method:
[nsIDOMEventListener::handleEvent]"  nsresult: "0x8057001c
(NS_ERROR_XPC_JS_THREW_JS_OBJECT)"  location: "<unknown>"  data: no]

Expected Results:  
The handleError function should have been called.
A messagebox should appear with the text error.

I have tested this scenario also in Firefox 1.5 and the same bug is in there as
well.
In Internet Explorer 6.0 this code works fine.
Confirmed using Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a1)
Gecko/20051011 Firefox/1.6a1.  Thanks for the simple testcase.
Assignee: nobody → events
Status: UNCONFIRMED → NEW
Component: General → DOM: Events
Ever confirmed: true
Keywords: testcase
Product: Firefox → Core
QA Contact: general → ian
Summary: when doing a throw in an eventhandler listed with addEventListener no error is thrown but the javascript console displays a Firefox error → |throw| in an event handler attached with addEventListener does not cause onerror function to be called
Version: unspecified → Trunk
XPConnect issue -- nsXPCWrappedJSClass::CheckForException unsets the exception on the JS context and reports the error to the console, but the DOM script error reporter is never called...
Assignee: events → dbradley
Component: DOM: Events → XPConnect
OS: Windows XP → All
QA Contact: ian → pschwartau
Hardware: PC → All
Flags: blocking1.9a2?
QA Contact: pschwartau → xpconnect
Flags: blocking1.9a2? → blocking1.9-
Whiteboard: [wanted-1.9]
So I looked into this a bit.  The thing is... XPConnect overrides the JSContext exception reporter with xpcWrappedJSErrorReporter, which mostly does absolutely nothing.  Why do we do that?  I'd think that we'd actually want to report exceptions to the standard error reporter for the JSContext, no?  Or are we trying to cover cases where JS calls into C++ which calls into JS and the outer JS wants to catch exceptions thrown on the inner JS?  Given that we end up reporting in nsXPCWrappedJSClass::CallMethod after trying the JS_Invoke anyway, I don't think that's the case...
Note also bug 66453
Depends on: 66453
Assignee: dbradley → nobody
I found the same bug in:
Mozilla/5.0 (Windows; U; Windows NT 5.1; pt-BR; rv:1.8.1.1) Gecko/20061204 Firefox/2.0.0.1
 (and other versions for the same os...)

while trying to do a system that catches all javascript errors and try to:
 1 - give the user some information about the error (if it isn't mine)
 2 - log it into a database
 3 - let the browser do the default action
Flags: wanted1.9+
Whiteboard: [wanted-1.9]
Assignee: nobody → honzab
Status: NEW → ASSIGNED
This bug is blocking functionality that is core to good debugging of JavaScript.

I have developed an error handling model that captures information and re-throw's errors up the call stack until it finally hits the main error hander window.onerror. At that point, all error information is serialized into a single error dump that can be dumped to give very verbose and easy to debug error. This methodology has worked amazingly and works for both IE and Mozilla, allowing me to write and troubleshoot very complex JS applications.

Without this, it is makes Mozilla as hard to debug as IE :-o

I vote to increase the severity of this bug as it significantly cripples our ability to troubleshoot our JS applications in a consistent and predictable way.

Thanks for your time.
- TCQ
Yeah, we should fix this in 3.0.x if we can find a branch-safe way to do so.

Honza: any progress to report?  bz's comment 4 describes a somewhat-puzzling state of affairs!
Flags: wanted1.9.0.x+
Assignee: honzab → nobody
Status: ASSIGNED → NEW
Mike, I will probably not have much time now to work on this bug. But if there is not anyone other who could, reassign back to me.
Blocks: 435025
I think we're past caring about this for 3.0.x, but if we want it anywhere it seems like it should be wanted for more recent releases.
Flags: wanted1.9.0.x+ → wanted1.9.1?
Confirmed that this doesn't work in Firefox 5.0.1 / Mac OS X 10.6

+1 vote to increase severity. Since most JS functions are triggered by events and handlers, this bug doesn't let us catch most errors. Especially relevant now that more and more browser-apps are turning into pure JS apps, and the need for error-reporting will only increase.
Attached file revised test case
Tested Firefox 6.0.1 and (with this revised test case), and it looks like onerror is called properly.
Close this out?
Attachment #560383 - Attachment mime type: text/plain → text/html
Both test cases work for me in nightlies, so I think closing this is fine.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: