Closed
Bug 55111
Opened 24 years ago
Closed 24 years ago
Wording in BasicAuth username/password dialog says "Confirm Password"
Categories
(Core :: Networking: HTTP, defect, P3)
Core
Networking: HTTP
Tracking
()
RESOLVED
FIXED
People
(Reporter: bzbarsky, Assigned: bugs)
References
Details
Attachments
(3 files)
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
patch
|
Details | Diff | Splinter Review |
Build ID: 2000100308
The wording before the password field says "Confirm Password" instead of
"Password" when I am prompted for a login by a site that uses BasicAuth over
SSL.
This looks really strange.
Comment 1•24 years ago
|
||
i believe this is a UI issue.
Assignee: asa → hangas
Component: Browser-General → User Interface: Design Feedback
QA Contact: doronr → mpt
Comment 2•24 years ago
|
||
Maybe, but it's not a design issue, just an obvious bug. Over to Networking.
Assignee: hangas → gagan
Component: User Interface: Design Feedback → Networking
QA Contact: mpt → tever
Reporter | ||
Comment 3•24 years ago
|
||
This bug only appears when the password manager is disabled. If the password
manager is enabled (that is, there is the little "remember password" checkbox),
the wording is correct.
Looks like something somewhere is passing in the wrong resource value....
Reporter | ||
Comment 4•24 years ago
|
||
Hmm. When the password manager is disabled, the dialog is brought up by
nsDOMWindowPrompter::PromptUsernameAndPassword
When the password manager is enabled, the dialog is brought up by
nsDOMWindowPrompter::UniversalDialog
Long-term, the problem will probably be fixed by coverting everything to
UniversalDialog....
Reporter | ||
Comment 5•24 years ago
|
||
Reporter | ||
Comment 6•24 years ago
|
||
Notes about the patch I just attached:
I traced the "problem" to xpfe/global/resources/content/commonDialog.js
In that file, the onload function would test whether we wanted two input fields,
and if so set up the second field as a "confirm password" field and _then_
checking whether the first field should be a "login" or "password" field.
This behavior did not appear when password manager was turned on because then
labels for all the fields were passed in and so the default labels (coming from
xpfe/global/resources/locale/en-US/commonDialog.dtd) were not used.
In any case, the proposed solution is the one that does not involve hacking the
dialog creation code to pass in labels. It's a partial solution at best, since
the labels with password manager off still differ from the labels with password
manager on ("User Name:" and "Password:" vs "User Name" and "Password").
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Linux → All
Hardware: PC → All
Reporter | ||
Comment 7•24 years ago
|
||
Reporter | ||
Comment 9•24 years ago
|
||
Comment 10•24 years ago
|
||
r=doron on newest patch, tested also on linux and works like a charm.
Reporter | ||
Comment 11•24 years ago
|
||
Alec, could you sr this?
Comment 12•24 years ago
|
||
sr=alecf
Comment 13•24 years ago
|
||
checked in.
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•