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)

x86
Windows 95
defect

Tracking

()

VERIFIED DUPLICATE of bug 63672

People

(Reporter: bht237, Unassigned)

Details

(Keywords: qawanted)

Attachments

(1 file)

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.
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 → ---
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 ago24 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 → ---
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 ago24 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 → ---
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
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
Mass-reassigning bugs to dom_bugs@netscape.com
Assignee: jst → dom_bugs
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 ago21 years ago
Resolution: --- → DUPLICATE
verified.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: