318146 - Saved HTTP auth password in keychain not used when "Allow saving in Keychain" unchecked

Status: RESOLVED FIXED

(Camino Graveyard :: OS Integration, defect)

Description

[theseum]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8) Gecko/20051107 Camino/1.0b1
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8) Gecko/20051107 Camino/1.0b1

This is related to bug 187720 but it seemed sufficiantly different that it should have its own bug.  Basically the problem is that if you have "allow saving in the keychain" disabled in the preferences, the dialog for supplying HTTP authorization still gives a "store password in keychain" option.  If you check that option, you might be surprised when you next go to that page, only to discover that your password is not, in fact, saved.

Reproducible: Always

Steps to Reproduce:
1.  Disable "save passoword in keychain"
2.  Login to a page that uses HTTP AUTH; check "store password in keychain" in the dialog
3.  Quit your browser and go back to the page.

Actual Results:  
Password isn't saved.

Expected Results:  
Password should be saved, or the "save password in keychain" checkbox shouldn't be there, or it should give you a warning when you try to use it.

Comment 1

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

I just tried this and Camino saved the password in the keychain when I checked that box on the auth sheet.  (Seems like the box is the prefs is just to indicate whether the box on the sheet should be checked by default or not).

Comment 2

[theseum]

The password gets stored, but it doesn't get used.  This is very nonintuitive, when the user checks "store password" they expect it to show up next time the go to the page.

Comment 3

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

OK, I see that now (the password *will* get used if you ever flip the pref back to "allow").

It seems like that one pref option controls two things, 1) saving passwords (which on httpAuth sites can be overridden on the sheet) and 2) using saved passwords, which does make it confusing.

I can't imagine a *normal* scenario where a user would want to use saved passwords but not save them, so the easiest solution here is probably to disable that checkbox on the sheet when the pref for "allow saving" is unchecked.

Comment 4

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Actually, why is that checkbox even on the sheet at all?  Is there some reason we want to allow people to opt-out of saving httpAuth passwords when the pref is set to save passwords (there's no such opt-out for webforms)?

Comment 5

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

(In reply to comment #4)

Er, nevermind, we do let people opt-out of saving webforms passwords (remember, don't remember now, never remember), but that sheet doesn't appear at all when the "allow saving" pref is unchecked.

So we should just disable the problematic box on the httpAuth sheet when "allow saving" is unchecked, and then we'll be consistent and non-confusing (I hope).

Comment 6

[theseum]

IMHO the http auth password saving should ignore the preference completely and the "store this password" checkbox should be its only control. (in other words, resolve bug 187720).  But that's just me.  In any case thanks for  listening and I don't think I have anything further to add!

Comment 7

[Stuart Morgan]

This was fixed by the patch for bug 355033; the pref only applies to web forms now.