Closed Bug 52120 Opened 21 years ago Closed 20 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: 20 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.