Closed Bug 400680 Opened 17 years ago Closed 9 years ago

Login Manager should not prompt for Master Password if signon.autofillForms is set to false

Categories

(Toolkit :: Password Manager, defect)

defect
Not set
normal

Tracking

()

RESOLVED WONTFIX

People

(Reporter: mail, Unassigned)

References

(Blocks 1 open bug)

Details

Attachments

(1 file, 1 obsolete file)

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; de; rv:1.8.1.8) Gecko/20071008 Firefox/2.0.0.8
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a8) Gecko/2007091211 GranParadiso/3.0a8

If signon.autofillForms is set to false, Login Manager should not prompt for the Master Password.

Reproducible: Always

Steps to Reproduce:
1. Set signon.autofillForms to false (using about:config)
2. Allow Login Manager to remember password for a login site
3. Restart Firefox (to clear Master Password) and revisit the login site
Actual Results:  
The user is prompted to enter the Master Password although nothing is to be filled in as signon.autofillForms is set false.

Expected Results:  
Nothing ;) - no master password prompt.
Attached patch Patch, work in progress v.1 (obsolete) — Splinter Review
I wasn't sure if this would be feasible, because of the bits of the code that wants logins to compare against username fields and such... But after poking at it for a bit, I think this can actually end up working.

The one bit I didn't look at is how well the autocomplete stuff deals with being attached when no logins are available. But that ought to work (or be fixed to).

Note to self: this is a whitespace-ignored diff, as I removed a if() { } block that was wrapping a bunch of code.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Will the fix make it into Firefox 3?
I'm asking because the issue is still there with the latest beta 5.
It won't make the initial release, but it should be small enough to take in an update (3.0.x).
Attached patch Patch v.2Splinter Review
Updated patch, also deals with deferring master password prompting when autocomplete=off is present (from bug 362576).
Attachment #285779 - Attachment is obsolete: true
When will the 3.0.x update come, do you know this already? It's really annoying if you browse on a site and the master password demand prompts on every single page if you don't want to login and enter your master password.
I added the patch to my firefox, now there is a even worse bug ;)
The master password prompts on every single character when typing your username into a login formular. This is a common usecase when logging in with another account, which isnt managed by the password manager.
Version: unspecified → Trunk
Ugh. So, I've poked at this a bit more, and a proper fix is going to be complex.

Bug 439365 adds even more trickyness, in that we now fire a notification when we selected a login to autofill but didn't (because autofillForms is false). This is nice because it avoids sending any notification unless there's something actually would have been done (ie, so that if some UI asked the user if they want to fill the form, something would actually happen).

It's not really possible to do that without possibly triggering a master password prompt, although we could just blindly fire a notification. That will often be ok, because we only get that far if we know there's at least 1 login matching the host + formSubmitURL. We could add an API like wouldTriggerMasterPassword(hostname, formSubmitURL, httpRealm) to only fire blindly when we need to avoid a master password prompt, but... ugh.

A further complication is that nsIAutocompleteResult usage seems to be quirky. What needs to happen (to avoid the problem in comment 6) is that if we can't get any logins with a search string of "", we shouldn't try again for future searches. But it seems something in the form controller is suppressing previous nsIAutocompleteResults when they're empty, which means we can't carry around any kind of "no, really, we won't have any results" state between invocations. That might be hard to fix without breaking other use cases. Maybe we can just detach the login manager autocomplete stuff when we know we're just going to give up, not sure.
Product: Firefox → Toolkit
This bug is still a serious annoyance to users.  The master password dialog steals focus, obscures content, and generally gets in the way.

One UI improvement that would mitigate the problem would be to make the master password dialog more like the "remember this login" bar, which does not interrupt the user's work.
Well, it' been nearly a year now since the last comment on this bug was made and FF's version is 3.0.13 and 3.5.2. But this annoying bug still is present. :-(
See also bug 513534, "Login forms in background tabs should never cause master password dialog to appear".
(In reply to comment #7) 
> A further complication is that nsIAutocompleteResult usage seems to be quirky.
> What needs to happen (to avoid the problem in comment 6) is that if we can't
> get any logins with a search string of "", we shouldn't try again for future
> searches. But it seems something in the form controller is suppressing previous
> nsIAutocompleteResults when they're empty, which means we can't carry around
> any kind of "no, really, we won't have any results" state between invocations.

I think that this quirk was bug 496466 which is now resolved.
>I think that this quirk was bug 496466 which is now resolved.
Not really. On FF 3.6 (Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6)the bug is always present.
I think the extension Master Password+:

https://addons.mozilla.org/en-US/firefox/addon/256173/

is an effective method of managing this bug, just in case anyone was wondering.

It may be configured to replace the prompt with a sound and an icon in the awesome bar.

Also this extension has apparently been around for a while (I'm not sure about this feature of it though) but this is the first time I've heard about it, so hopefully this post will assist people looking for a solution.
(In reply to comment #14)
> I think the extension Master Password+:
> 
> https://addons.mozilla.org/en-US/firefox/addon/256173/

that's a good solution (which I am also using for quite long).
it is one of those extensions that mozdevs are trying to write but they can't.
Has the FX own Master Password to be disabled ins such case?

How about the Mozillas broad recommendation, do not use a lot of extensions?
High number of extensions installed can decrease the perfomance.
I guess, part of affected users can balance on such limit without MPP.
It's generally agreed among UX/Engineering/Product that we don't want to further develop the existing master password functionality, as it's a poor fit for current needs and our current direction in this area.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: