Closed
Bug 200236
Opened 21 years ago
Closed 21 years ago
Change Master password dialog OK button disabled with matching passwords
Categories
(Core Graveyard :: Security: UI, defect, P1)
Tracking
(Not tracked)
VERIFIED
FIXED
psm2.4
People
(Reporter: kenta, Assigned: KaiE)
References
()
Details
(Keywords: regression)
Attachments
(1 file)
2.01 KB,
patch
|
javi
:
review+
alecf
:
superreview+
|
Details | Diff | Splinter Review |
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•21 years ago
|
Version: unspecified → 2.4
Assignee | ||
Comment 1•21 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•21 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•21 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•21 years ago
|
||
Assignee | ||
Comment 5•21 years ago
|
||
Comment on attachment 119971 [details] [diff] [review] Patch v1 Javi, can you please review?
Attachment #119971 -
Flags: review?(javi)
Comment 7•21 years ago
|
||
Comment on attachment 119971 [details] [diff] [review] Patch v1 r=javi
Attachment #119971 -
Flags: review?(javi) → review+
Assignee | ||
Comment 8•21 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•21 years ago
|
||
Comment on attachment 119971 [details] [diff] [review] Patch v1 sr=alecf
Attachment #119971 -
Flags: superreview?(alecf) → superreview+
Assignee | ||
Comment 10•21 years ago
|
||
checked in, fixed
Status: ASSIGNED → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
Updated•21 years ago
|
Flags: blocking1.4b?
Assignee | ||
Comment 11•21 years ago
|
||
*** Bug 203538 has been marked as a duplicate of this bug. ***
Updated•8 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•