If you get the password wrong (or think you've got it wrong) when you go through the autoconfig process, the only way to edit it is to start again. STR: 1) Enter Details with incorrect password, select Go. 2) Autoconfig finds details 3) Select Create Account 4) Autoconfig tries to login, complains that username or password are wrong. Expected results: Allow me to edit username and/or password Actual results: If password, start again. If username, edit server details, then start server detection again.

expect I got this too, but seems to be "fixed" in Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9.1pre) Gecko/20090616 Lightning/1.0pre Shredder/3.0b3pre now on, it seems to be irrelevant what username / password is given, no "check username" dialog appears ;(

(In reply to comment #1) > expect I got this too, but seems to be "fixed" in > Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9.1pre) Gecko/20090616 > Lightning/1.0pre Shredder/3.0b3pre Nope still broken on Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1pre) Gecko/20090624 Shredder/3.0b3pre > now on, it seems to be irrelevant what username / password is given, no "check > username" dialog appears ;( It checks the username/password after it has found the server and you say create account (as per my step 3/4). I'm setting this as blocking as I think we should fix this - as if you do get it wrong and just want to retry the password, then you don't want to have to start again, especially if you have non-standard set ups.

Does this need additional UI (and therefore localizable strings) or can we re-use some existing UI for this?

I think we'll need some extra UI for this. Andreas, can you confirm that, and possibly come up with a new layout that includes the password in Bug 506290? Thanks, Blake.

(In reply to comment #4) > I think we'll need some extra UI for this. Andreas, can you confirm that, and > possibly come up with a new layout that includes the password in Bug 506290? Andreas, we still need your confirmation here to assess the l10n impact of this bug.

Simon, I think all the work is going to happen in Bug 506290, since I'll be mucking all over that part of the code in that bug. Does it make sense to close this one as a dupe?

If you are sure, that this will all be covered in bug 506290, then it's okay to dupe this bug against bug 506290.

Probably the best option for now is to set it as a dependency. Then a) we have a clear bug for it that is open b) when bug 506290 is fixed we know to check this bug as well.

Fixed in bug 506290.