Change Master password dialog OK button disabled with matching passwords

VERIFIED FIXED in psm2.4

Status

Core Graveyard
Security: UI
P1
blocker
VERIFIED FIXED
16 years ago
2 years ago

People

(Reporter: Ken Takusagawa, Assigned: kaie)

Tracking

({regression})

1.0 Branch
psm2.4
x86
Linux
regression

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment)

2.01 KB, patch
Javier Delgadillo
: review+
Alec Flett
: superreview+
Details | Diff | Splinter Review
(Reporter)

Description

16 years ago
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4a) Gecko/20030401
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4a) Gecko/20030401

When selecting a Master password for the first time, the OK button is
grayed-out even after entering matching passwords.

Slightly weirder is that after entering matching passwords, hitting
the HOME button in the second password prompt enables the OK button.

The above URL triggers the Change Master Password, but only works for MIT 
students (sorry).  I doubt it is a problem specific to the site.


Reproducible: Always

Steps to Reproduce:
1. Go to a site that stores does certificates or somehow triggers the 
Change Master Password Dialog.
2. Enter two matching passwords, using TAB to switch between the prompts


Actual Results:  
OK button grayed out

Expected Results:  
OK button not grayed out.

Works fine in 1.3

Updated

16 years ago
Version: unspecified → 2.4
(Assignee)

Comment 1

16 years ago
Confirming. This looks seriously broken.
Assignee: ssaux → kaie
Severity: normal → blocker
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: nsbeta1+
Priority: -- → P1
Target Milestone: --- → 2.4
(Assignee)

Comment 2

16 years ago
It works correctly with 1.3, regression.
I don't see *any* checkin to the security UI code after the date where the trunk
branched for 1.3, so it seems very likely something else in Mozilla caused this
new behaviour as a side effect.
Keywords: regression
(Assignee)

Comment 3

16 years ago
It seems that onkeypress events are now handled differently.
It seems, in the past the onkeypress handler was called *after* the key arrived
in a text field.
Now it seems, the onkeypress handler gets called *before* the key arrives.

This breaks the behaviour of this dialog, because it expects to be called after.

I found a workaround. By not using onkeypress, but using oninput the dialog
appears to work again. I'll attach a patch.

cc'ing bryner, aroonl, jkeiser. Timeless said, you might have changed the
behaviour? Since I have a workaround, no action is necessary, but cc'ing you
anyway, in case you changed the behaviour accidentially.
Status: NEW → ASSIGNED
(Assignee)

Comment 4

16 years ago
Created attachment 119971 [details] [diff] [review]
Patch v1
(Assignee)

Comment 5

16 years ago
Comment on attachment 119971 [details] [diff] [review]
Patch v1

Javi, can you please review?
Attachment #119971 - Flags: review?(javi)
(Assignee)

Comment 6

16 years ago
Nominating as a blocker for 1.4 beta.
Flags: blocking1.4b?

Comment 7

16 years ago
Comment on attachment 119971 [details] [diff] [review]
Patch v1

r=javi
Attachment #119971 - Flags: review?(javi) → review+
(Assignee)

Comment 8

16 years ago
Comment on attachment 119971 [details] [diff] [review]
Patch v1

Alec, can you please review this tiny patch?
Attachment #119971 - Flags: superreview?(alecf)

Comment 9

16 years ago
Comment on attachment 119971 [details] [diff] [review]
Patch v1

sr=alecf
Attachment #119971 - Flags: superreview?(alecf) → superreview+
(Assignee)

Comment 10

16 years ago
checked in, fixed
Status: ASSIGNED → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → FIXED

Updated

16 years ago
Flags: blocking1.4b?
(Assignee)

Comment 11

15 years ago
*** Bug 203538 has been marked as a duplicate of this bug. ***

Comment 12

15 years ago
Verified.
Status: RESOLVED → VERIFIED

Updated

14 years ago
Component: Security: UI → Security: UI
Product: PSM → Core

Updated

10 years ago
Version: psm2.4 → 1.0 Branch
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.