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)
Tracking
()
RESOLVED
FIXED
mozilla0.9.6
People
(Reporter: martin.honnen, Assigned: jst)
References
Details
(Keywords: dom0, Whiteboard: [HAVE FIX])
Attachments
(4 files)
|
255 bytes,
text/html
|
Details | |
|
2.89 KB,
patch
|
Details | Diff | Splinter Review | |
|
9.20 KB,
patch
|
Details | Diff | Splinter Review | |
|
9.12 KB,
patch
|
john
:
review+
jband_mozilla
:
superreview+
|
Details | Diff | Splinter Review |
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).
| Reporter | ||
Comment 1•25 years ago
|
||
Comment 3•25 years ago
|
||
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.
Comment 4•25 years ago
|
||
Comment 5•25 years ago
|
||
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.
Build 2001012904
Still "object KeyEvent"
line number,column number,caller still missing
Comment 9•25 years ago
|
||
Tom, you gonna do this? If not, it should be reassigned.
/be
Keywords: mozilla1.0
| Assignee | ||
Comment 10•24 years ago
|
||
*** Bug 67645 has been marked as a duplicate of this bug. ***
Comment 11•24 years ago
|
||
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
Comment 12•24 years ago
|
||
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.
Comment 13•24 years ago
|
||
jst, little help?
/be
| Assignee | ||
Comment 14•24 years ago
|
||
Taking.
Assignee: joki → jst
Status: ASSIGNED → NEW
Target Milestone: Future → mozilla0.9.5
Comment 15•24 years ago
|
||
is bug 79133 depend on this?
| Assignee | ||
Comment 16•24 years ago
|
||
| Assignee | ||
Comment 17•24 years ago
|
||
The attached patch is missing null checks after the calls to
JS_NewUCStringCopyZ(), I added those locally.
| Assignee | ||
Updated•24 years ago
|
Status: NEW → ASSIGNED
Whiteboard: [HAVE FIX]
| Assignee | ||
Updated•24 years ago
|
Target Milestone: mozilla0.9.5 → mozilla0.9.6
| Assignee | ||
Comment 18•24 years ago
|
||
| Assignee | ||
Comment 19•24 years ago
|
||
jband, wanna sr= this one?
Comment 20•24 years ago
|
||
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 21•24 years ago
|
||
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+
| Assignee | ||
Comment 22•24 years ago
|
||
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.
Description
•