Wait for username input instead of showing "select user" dialog when multiple usernames/passwords are stored

RESOLVED FIXED in Future

Status

SeaMonkey
Passwords & Permissions
P3
enhancement
RESOLVED FIXED
17 years ago
8 years ago

People

(Reporter: Ian Thomas ('thelem'), Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

17 years ago
CURRENT BEHAVIOUR:
If more than one username/password has been saved for a specified user, then a
dialog box will appear asking them to choose which username/password to enter
into the form.

PROBLEM WITH CURRENT BEHAVIOUR:
This method is intrusive, the user is asked to select a username even if they do
not wish to login. If ever page on a site includes a login form, then the user
is prompted for a username/password every time they load a page.

PREFERRED BEHAVIOUR:
*When there are mutliple matches* no changes should be made to the values in the
form and the user should not be prompted.

When the user puts the focus in the username field, an autocomplete widget
should appear listing the possible usernames to select from.

Alternatively, a combobox could be used, but AFAIK mozilla does not support
these, and the extra width may interfere with the layout of the page.

Comment 1

17 years ago
Target->future
P3
Priority: -- → P3
Target Milestone: --- → Future
Version: unspecified → 2.0

Comment 2

17 years ago
Mass assigning QA to ckritzer.
QA Contact: junruh → ckritzer

Comment 3

17 years ago
Platform > all
QA Contact: ckritzer → junruh
Hardware: PC → All
Summary: Handling of multiple username/password matches is poor → [RFE] Handling of multiple username/password matches is poor
Version: 2.0 → 2.1

Comment 4

16 years ago
I believe this bug refers to basic authentication, not to crypto.

Changing component.
Assignee: ddrinan → mstoltz
Component: Client Library → Security: General
Product: PSM → Browser
QA Contact: junruh → bsharma
Version: 2.1 → other
Actually it's password manager -> morse
Assignee: mstoltz → morse
Component: Security: General → Password Manager
QA Contact: bsharma → tpreston

Updated

16 years ago
Summary: [RFE] Handling of multiple username/password matches is poor → Handling of multiple username/password matches is poor

Comment 6

16 years ago
I would dislike this change. Most sites that I can imagine having multiple
accounts on have a specific login page. The current behaviour is optimal in this
case.

The proposed behaviour would force me to click on the username field, then deal
with some autocomplete widget! Yuk! This would be a massive increase in effort
and wreck one of Mozilla's best time-saving features.
(Reporter)

Comment 7

16 years ago
Take Mozillazine for example. If you have submitted two responses and saved
username both times, then that is counted as two usernames so you get a popup on
every single page.

There are many pages on the internet with the same problem (my own -
www.LemNet.com - being one of them).

Comment 8

16 years ago
I would like to see this fixed, too.  I'm using Phoenix, though, so I don't know
if this will help me.  

I have two sites (Mozillazine being one) that have the incorrect username/pw
recorded and I can't figure out how to remove or edit them. (Searching bugzilla
for Phoenix and password manager hasn't helped...)
Reassigning to new module owner.
Assignee: morse → dveditz

Comment 10

16 years ago
I would actually love the current behaviour of presenting a dialog, _if_ a
"Submit" button was added to it (bug 131987). In that case, I would even want it
to pop up every time, even when only one login is saved.

But I can see that for sites that have a login form on each page, this is a big
problem. So, how about having a "don't show this dialog next time" checkbox?
When it would be checked, the password manager would prefill the first/default
login and provide autocomplete for entering other logins.

Updated

15 years ago
Summary: Handling of multiple username/password matches is poor → Wait for username input instead of showing "select user" dialog when multiple usernames/passwords are stored
Product: Browser → Seamonkey
(Reporter)

Comment 11

13 years ago
fixed in firefox

Comment 12

13 years ago
yes, I think the updated behavior (in Firefox) is usable.
Assignee: dveditz → nobody
QA Contact: tpreston

Comment 13

9 years ago
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614
Status: NEW → UNCONFIRMED

Comment 14

9 years ago
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 15

9 years ago
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 16

9 years ago
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 17

9 years ago
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 18

9 years ago
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 19

9 years ago
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 20

9 years ago
I think this has been fixed for SeaMonkey 2.0 with the switch from Satchel to Wallet.

Comment 21

8 years ago
> I think this has been fixed for SeaMonkey 2.0 with the switch from Satchel to
> Wallet.
Correct.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.