Closed Bug 52120 Opened 25 years ago Closed 24 years ago

window.onerror fires but with the wrong arguments [4xp]

Categories

(Core :: DOM: Core & HTML, defect, P3)

x86
Other
defect

Tracking

()

RESOLVED FIXED
mozilla0.9.6

People

(Reporter: martin.honnen, Assigned: jst)

References

Details

(Keywords: dom0, Whiteboard: [HAVE FIX])

Attachments

(4 files)

window.onerror in NN4 is a error handler with three arguments error message file url line number but with M17 the handler fires but passes only one strange KeyEvent object as an argument. Though Mozilla with JavaScript 1.5 has try/catch exception handling in the core language and therefore much less need for window.onerror it should be kept working as in NN4 (or left out totally).
Reassigning to Joki.
Assignee: jst → joki
I'd nominate this but the best we could do anyway is get the error message and maybe the url. Line number isn't currently be set on JS messages and that isn't going to get fixed righ now either. Unfortunately I'll have to mark it future.
Status: NEW → ASSIGNED
Keywords: 4xp
Target Milestone: --- → Future
I wrote a small patch to call onerror with the right arguments. Unfortunately I couldn't find a clean and simple way to pass the required information from the javascript error handler to the event-caller. So I took an unclean but simple way: pass an nsGUIEvent instead of nsEvent because nsGUIEvent has a void pointer where the error information can be stored. I haven't checked if the DOM 1+ event handling is affected (rightly or wrongly) by this patch.
Please enlighten me, because I am struggling with more than one issue here. try/catch is really good but 1) There is no way to avoid a script error in Microsoft Internet Explorer 4, so it ca't be used in real life yet. Let me assume for the moment that I write a separate page for try/catch capable browser. How can I globally catch uncaught exceptions and print a stack trace without window.onerror? Suppose I code something like <SCRIPT> VAr meStupidProgramer=null; </SCRIPT> Obviously a typo or could even be a transmission error. 2) Ideally, somehow I should be able to cover all my scripts in all frames (not only per frame/window) globally by a global try/catch block that catches all uncaught exceptions. 3) Currently, even with the old window.onerror scheme, I find myself in the awkward position having to register every page I load with an error handler. What is really not logical in my opinion is the fact that the error handler doesn't stick with the frame window (as the name implies) but gets wiped out with every new docoment as if it was called document.onerror. This becomes critical where such content having script events is generated via document.write() 4) I cannot set the error handler within the write() string because browser don't like this, even with correct escaping as follows: document.write("<HTML><HEAD><S"+"CRIPT>window.onerror=top.someHandler;<"+"/SCRIPT>" </HEAD><BODY>Form elements etc having script events in here</BODY></HTML>"); although this would ensure that the window would re-register itself on refresh of the content without being written again via history operations etc. 5) I don't know how to get a stack trace. This is possible with Navigator 4 via function.caller. 6) How do I get the column number where the error occurs? HTML is not line oriented at all (otherwise there would probably a single line comment mechanism) and JavaScript allows to write an unlimited number of statements on a single line. Microsoft Internet Explorer reports the column number in a dialog box but so far I have not been able to get this info in a script. I am writing applications and not web pages. The applications would be fragile and have erratic behaviour without robust error handling. The current browser environment on the web is dictated by the lowest common denominator af those browsers a site supports. Netscape Navigator 4 currently holds the top position under these constraints as far as robustness in this area is concerned, simply because it supports function.caller allowing me to get a stack trace. Mozilla has new functionality that with my current knowledge cannot be exploited to get similar results. Someone please tell me that I am wrong, honestly.
any status on this?
Keywords: patch
Build 2001012904 Still "object KeyEvent" line number,column number,caller still missing
Tom, you gonna do this? If not, it should be reassigned. /be
Keywords: mozilla1.0
Keywords: dom0
*** Bug 67645 has been marked as a duplicate of this bug. ***
This really ought to be fixed for 1.0. At least fix it partially: It should pass three arguments of the expected types, even if the third argument isn't actually a useful line number. David Flanagan
Adding keyword ecommerce. We would love to include Mozilla/Netscape 6 in the array of browsers that we recommend for our web based products. Currently the lack of an error handler is the ONLY bug that prevents us from doing so. BTW the browser is otherwise quite amazing.
jst, little help? /be
Taking.
Assignee: joki → jst
Status: ASSIGNED → NEW
Target Milestone: Future → mozilla0.9.5
is bug 79133 depend on this?
The attached patch is missing null checks after the calls to JS_NewUCStringCopyZ(), I added those locally.
Status: NEW → ASSIGNED
Whiteboard: [HAVE FIX]
Target Milestone: mozilla0.9.5 → mozilla0.9.6
Blocks: 84512
jband, wanna sr= this one?
Comment on attachment 56052 [details] [diff] [review] Updated patch, use JS_PushArguments() for argument handling when calling onerror handlers r=jkeiser,jst-review.pl
Attachment #56052 - Flags: review+
Comment on attachment 56052 [details] [diff] [review] Updated patch, use JS_PushArguments() for argument handling when calling onerror handlers sr=jband
Attachment #56052 - Flags: superreview+
Fixed.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: