Closed
Bug 118464
Opened 24 years ago
Closed 21 years ago
Error handler catches warning even with correct werror preference
Categories
(Core :: DOM: Core & HTML, defect, P4)
Tracking
()
People
(Reporter: bht237, Unassigned)
Details
(Keywords: qawanted)
Attachments
(1 file)
750 bytes,
text/html
|
Details |
With the following user preferences
user_pref("javascript.options.strict", true);
user_pref("javascript.options.werror", false);
any JavaScript warnings should be logged in the console but they should not be
caught by an error handler in an HTML page.
The attached testcase fails in build 2002010203 on Win95.
You should not see any JavaScript alert when loading the testcase.
Comment 2•24 years ago
|
||
Yes they should, if you tell the JS engine to treat JS warnings as errors, they
will be handed to window.onerror.
INVALID.
Status: UNCONFIRMED → RESOLVED
Closed: 24 years ago
Resolution: --- → INVALID
I intended to tell the JS engine to NOT treat warnings as errors.
Maybe I misunderstand the syntax:
user_pref("javascript.options.werror", false);
I thought false for "not", true for "yes".
How exactly is this option to be set if not as above?
In the testcase, both settings result in failure.
Where can I find any reference documentation on this option?
Many thanks.
Status: RESOLVED → UNCONFIRMED
Resolution: INVALID → ---
Comment 4•24 years ago
|
||
Um, oops, misread the testcase, however, this has been discussed before
(unfortunately not in a public forum), and mozilla is supposed to call
window.onerror for strictness warnings, and there was already a bug on this
earlier. Duping.
*** This bug has been marked as a duplicate of 63672 ***
Status: UNCONFIRMED → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → DUPLICATE
Bug 63672 may be invalid because it does not contain any reference to the option
user_pref("javascript.options.werror", false);
I would think for this reason it is not a duplicate of this one.
The werror option appears to be designed to control whether warnings reach
window.onerror or not.
Maybe the patch in bug 63672 will work here if it uses the werror switch.
Status: RESOLVED → UNCONFIRMED
Resolution: DUPLICATE → ---
Comment 6•24 years ago
|
||
Nope, werror only controls whether or not the JS engine should stop execution of
the script when a warning occures. window.onerror is called regardless of the
severity of the error (i.e. even if it is a warning and not a real error).
Duping again.
*** This bug has been marked as a duplicate of 63672 ***
Status: UNCONFIRMED → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → DUPLICATE
Johnny Stenback's comments appear to be in conflict with previous statement from
Brendan Eich and Mike Shaver below.
There is a significant difference in impact on an application between the two
interpretaions on werror.
An option to control whether a script should continue execution after a script
error does not need to be convoluted with the fact whether the error is a
genuine script error or a script warning IMHO.
Would someone please be so kind as to point out a publicly accessible piece of
documentation that clarifies this?
Many thanks.
From: Brendan Eich (brendan@meer.net)
Subject: Re: Does object have attribute?
Newsgroups: netscape.public.mozilla.jseng
Date: 2000-09-27 15:48:38 PST
"The strict option implies warnings, never errors. The werror option turns
warnings into errors, and may be composed with strict."
From: Mike Shaver (shaver@zeroknowledge.com)
Subject: Re: ECMAScript syntax question
Newsgroups: netscape.public.mozilla.jseng
Date: 2000-08-23 13:11:18 PST
"There's a pref that you can set: "javascript.options.strict", and a
related "javascript.options.werror" that turns warnings (strict-induced
or otherwise) into script-fatal errors."
Status: RESOLVED → UNCONFIRMED
Resolution: DUPLICATE → ---
Comment 8•24 years ago
|
||
jst, onerror predates warnings (strict or not), so I think it's a "little bit"
incompatible to call onerror for conditions that did not cause it to be called
in 4.x, 3.x, or 2.x. Thoughts?
/be
Status: UNCONFIRMED → NEW
Ever confirmed: true
Comment 9•23 years ago
|
||
Severity = LOW [No Crash, No severe functional failure, No Cosmetic failure]
Visibility = MEDIUM [Dont see any real world website usage, Gets one point of
compatibility with other browsers since it works on other browsers. gets one
more point on compliance with adopted techonology]
Priority = Visibility * Severity
Priority = p4
adding word "qawanted" because I'm setting this priority on available data & if
someone feels otherwise then please investigate this more & feel free to change
this priority.
Keywords: qawanted
Priority: -- → P4
![]() |
||
Comment 11•21 years ago
|
||
This is fixed, and jst was right when he dupped it.
*** This bug has been marked as a duplicate of 63672 ***
Status: NEW → RESOLVED
Closed: 24 years ago → 21 years ago
Resolution: --- → DUPLICATE
You need to log in
before you can comment on or make changes to this bug.
Description
•