Closed Bug 110454 Opened 24 years ago Closed 24 years ago

javascript strict warnings in password.js

Categories

(Core Graveyard :: Security: UI, defect, P3)

1.0 Branch
defect

Tracking

(Not tracked)

VERIFIED FIXED
psm2.2

People

(Reporter: bugzilla, Assigned: ssaux)

Details

Attachments

(1 file, 1 obsolete file)

When selecting Change Master Password Warning: reference to undefined property params.getString Source File: chrome://pippki/content/password.js Line: 42 Warning: assignment to undeclared variable i Source File: chrome://pippki/content/password.js Line: 51 build 20011115
Priority: -- → P3
Summary: javascript strict warnings in password.js → javascript strict warnings in password.js
Target Milestone: --- → 2.2
Attached patch proposed patch (obsolete) — Splinter Review
Kai, part of the patch does what resetpassword.js does. I suspect the old code using the try catch was only necessary because "arguments" was never checked. Can you review.
Keywords: patch, review
It is a good idea to replace the try block with the check you added. But I think this will not resolve the first strict warning, or have you checked? I wonder that no ";" is behind "params.getString(1)", I suggest we add one. This may or may not make that Warning on Line 42 disappear. We should test that. The "else path" now uses two pairs of brackets {{}}, I think you should remove one.
Attached patch revised patch.Splinter Review
Changes are: 1) add semicolon to the end of the GetString statement. 2) remove extra curly-braces. Note that I've tested this. The javascript warning was because the code read getString instead of GetString. I checked the idl for the nsIDialogParamBlock and made the change. With the previous patch, just as with this one, there are no warnings.
Attachment #58637 - Attachment is obsolete: true
Comment on attachment 58709 [details] [diff] [review] revised patch. looks good. r=kaie
Attachment #58709 - Flags: review+
see also bug 106939.
Comment on attachment 58709 [details] [diff] [review] revised patch. I think the try/catch was necessary since the QueryInterface() can fail and throw an NS_ERROR_NO_INTERFACE exception. If it doesn't fail and throw an exception then params is almost guaranteed not to be null. It's probably a good idea to restore it back to the way it was originally and just put in the getString to GetString change. sr=kin@netscape.com with the try/catch restored.
Attachment #58709 - Flags: superreview+
Kaie checked in an equivalent patch (cvs version 1.15) Marking fixed.
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Verified per ssaux's comment.
Status: RESOLVED → VERIFIED
Product: PSM → Core
Version: psm2.1 → 1.0 Branch
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: