Closed Bug 27821 Opened 25 years ago Closed 25 years ago

Remove "Save Password" checkbox from New Account Setup dialog

Categories

(SeaMonkey :: MailNews: Account Configuration, defect, P3)

defect

Tracking

(Not tracked)

VERIFIED INVALID

People

(Reporter: esther, Assigned: alecf)

Details

Using builds 2000-02-14 builds on win, mac and linux there is a checkbox in the Account Settings and New Account Setup up dialog that should be removed per conversation in bug 21781. The user will go to the Wallet area of preferences to disable save password, if they no longer want it enabled for mail and news. 1. Launch Messenger 2. Select Mail/News Account Settings from the Edit menu 3. Select a Server and notice there is a check box in the right panel titled "Save Password". This should be removed. 4. Select New Account and enter informatin and click Next until you get to the panel that has Server Information, notice there is a check box for Save Password, it should be removed.
QA Contact: lchiang → nbaca
I disagree with this and I think we should have the UI. I have hooked the checkbox up to wallet, so that when you uncheck the checkbox, it forgets your wallet password... and it will always reflect the state of your password in the wallet - if it's in there, it will be checked, if it's not, then it will not.
I didn't realize that the dialog in the account setup was hooked up to wallet (actually single-signon). In that case, then I agree with alecf that we should keep the checkbox. It gives us the best of both. But I thought the other bug report was saying that when you checked the checkbox in the account setup to save the password and then went to mail, you were still prompted for your password. Did I misunderstand that other bug report, or do we still have a problem?
I think we to all agree how this thing should work! :-) Ideally, it would be nice if Single Signon (SS) worked as follows, 1. During Account Setup Wizard, user checks "Remember my password" checkbox. SS dialog explaining feature, how to turn it off etc. is displayed. User enters SS password. Then when user connects to that account, they get SS dialog (or no dialog if they already provided their SS password). 2. Account Settings dialogs. "Remember my password" check box reflects if SS is enabled or diabled. From here, user can check or un check box and choice is reflected in SS database. If SS wasn't turned on for this account and user checks "Remember my password" checkbox, entered password is stored in SS database. If user hasn't used the SS feature before, checking the "Remember..." checkbox brings up the SS dialog and explains feature to user. 3. User attempts to connect to mail account. SS already enabled and user logged in, no password. User not already logged into SS, SS dialog appears. SS not enabled, user get Mail Password dialog. If user checks "Remember my password" checkbox, and SS feature already turned on for other account/feature, password stored in SS database. If user has never used SS feature before, checking the "Remember..." checkbox brings up the SS dialog and explains feature to user.
right, so the one tricky thing is this: imagine wallet does not know your password... so you check "remember password" .. that's #27475 the next time you log in, wallet prompts you for the password, and the "remember this value" is unchecked. The problem is basically that I have no way of saying "wallet, the next time you get asked for this password, default to remembering it".. I think this is reasonable though, I have one idea for an improvement after beta1. The only thing is right now, it's not sticky if you haven't remembered the password. I didn't think I had a way to fix that for beta 1, but I thought of one last night.... I need to run it by someone to make sure it's not a totally crazy idea, so I'll talk to seth today
Ok, discussed this with seth, I'm not removing this (ever) and the behavior I just checked in is how it will work for beta 1. I'll send out an e-mail to explain.
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → INVALID
Perhaps we can put the reasoning in Jennifer's single sign-on spec for mail?
This is a DRAFT right now and needs updating (turning on from Account Settings is not here yet) but here is the link. http://gooey/client/5.0/specs/mail/Misc/SingleSignon.html
In reading over the referenced draft that you just cited, and also in reading through this bug report and the related reports 27994 and 18565, I found myself a bit confused. I'll try to make comments on the draft and show where some of that confusion lies. > Once the user has enabled single signon for the desired components, s/he > needs only to sign on once and all passwords included in the single signon > feature are automatically supplied to the application or feature as necessary. What do you mean by enabling single signon for a desired component? There is an enable pref that affect whether single signon is used or not universally, not on a component by component basis. And what do you mean by a component? > Users can turn on Single Signon for Mail the first time they attempt to > authenticate to a Mail server. Same comment as above. I don't know what this means. From the next comment in your document it seems you are referring to checking the do-you-want-to-save checkbox in the dialog that prompts for password? If so, that doesn't turn on single-signon in any way (it was never off) but rather saves that one password. > Single Signon must be turned on for each Mail account separately. I think you meant to say "you must save your password for each mail account separately". That's different than turning on single-signon. > Process Flow The wording in this diagram could not be read. > Dialog 1 Looks like you are proposing adding a lot of wording to this dialog. The discussions that we've already had regarding this UI is that the box should be as simple as possible, otherwise it will look too imposing. We have just added some wording to the head of this box explaining that we are not currently encrypting but that we will do so in the future. This was added for legal reasons since beta1 will not be doing encryption -- the phrase will be yanked just as soon as we start encrypting. > Dialog 2 Same comment about being too imposing. Especially since this dialog will pop up every time the user saves a password (at least dialog 1 popped up once in the lifetime of the browser). But worse is that you are proposing that two dialogs pop up every time the user saves a password -- the original dialog asking for the password with the do-you-want-to-save checkbox and then this dialog describing the feature. I've already fielded too many bug reports about excessive dialogs being very bad and have strived to get to a minumum of dialogs. > If single signon is not enabled for a particular account, and then the > user wants to turn it on, how do they do this? Do they need to go to a > single signon dialog? Or can they turn it on for a particular account > by checking a "remember my password" box on a password dialog box? Either. Again my basic confusion. I don't understand what you mean when you say that they can go to a single-signon dialog to enable the feature. Nor do I know what you mean by enabling the feature. I do understand the second alternative but that is not "turning on" the feature -- it is remembering the password that particular time.
Thank you for the feedback. I have updated the spec to clear up some of these issues. http://gooey/client/5.0/specs/mail/Misc/SingleSignon.html Sorry for the confusing wording. Single Signon is a somewhat abstract concept and its hard to give a "name" to some of these concepts sometimes. This doc is still a draft and needs work. >What do you mean by enabling single signon for a desired component? There is >an enable pref that affect whether single signon is used or not universally, >not on a component by component basis. And what do you mean by a component? Component is the wrong word, "any instance for which a password is needed" is more correct i suppose. And you're right, its not enabling SS, but storing a particular password. >I think you meant to say "you must save your password for each mail account >separately". That's different than turning on single-signon. Yes, you're right. >Process Flow. The wording in this diagram could not be read. Click on the diagram and a full size version of the flow chart is displayed. Hopefully the flow chart will be useful. >Dialog 1. Looks like you are proposing adding a lot of wording to this dialog. Wording needs some work (and word reduction!). I think Vera in Tech pubs will be helping with this. The user should only see this dialog ONCE, when they enter their first password into the SS database. They won't see it again. Passwords are a serious thing and I think we need to be sure we properly inform users what they are being asked to do and how to modify things. Also, we need to let users know that this password dialog that pops up is part of Netscape and not part of the webpage they just loaded. I've heard a lot of folks say they weren't sure why they were seeing this dialog at first. >Dialog 2 Removed, too much, I agree. >I don't understand what you mean when you say that they can go to a >single-signon dialog to enable the feature. Nor do I know what >you mean by enabling the feature. I do understand the second alternative but >that is not "turning on" the feature -- it is remembering the password that >particular time. You're right, I was using the term 'enabling the feature' incorrectly. What i mean is 'remembering the password'. What I was also asking here was if there will be some central location (dialog in prefs?) were users can remove passwords from the SS database. Thanks for the feedback.
OK, everything's cool except your last comment. Your original remark was about enabling single signon (by which you meant saving passwords) and you spoke of going to a single-signon dialog to do that. Then you qualified it above by saying there would be a central location to remove passwords. That is true -- it's what we have been calling the signon viewer. But keep in mind that you cannot add passwords from the signon viewer, you can only delete them.
Verified Invalid. The checkbox is remaining according to Alec's statement.
Status: RESOLVED → VERIFIED
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.