2000112420MTrunk. In POP account, Get message and type a wrong password. The wrong password alert comes up and you OK. Password dialog again, and you enter a wrong password again and OK. Result: Nothing happens. From what I see in the status bar, no network activity takes place after the second password dialog. Expected result: Mozilla should send request to the server and another round of alert and password entry dialog should come up. This is different from bug 59942.

reassigning to naving

In MTrunk 2000121208, the bug is gone. In three different POP accounts, typing wrong password kept asking for a new one more than three times. Changing to WFM.

Marking verified (worksforme).

It is back now in 2001020208MTrunk. Mail tries to get message with a wrong password only twice.

The bug is gone again in 2001020908. Resolving as such.

VERIFIED, per reporter's comments.

It is back! 20010319110. This happens in the default POP account only. bug 71670 is now working better and Mozilla asks for correct password, but only once. If get mail fails for the second time from wrong password, it finishes job silently.

It does not ask for correct PW for default POP account, even after the first attempt fails. 2001040608 Mac trunk.

Yes I have also seen this sometimes. nominating because it may force you to shutdown and start again.

If the password fails, then let us start from the beginning because some servers close the connection when we send the username again as shown in the patch. When we send the username, we set the next state after response to send password. If the server never comes back to us, we would never prompt the user for password. So this becomes a deadlock. 4x code also starts from the beginning. cc bienvenu for review.

I just don't know about the pop code - your code seems reasonable - I don't know why Jeff did it the way he did. As long as you've tested it, sr=bienvenu

it looks ok to me too...r=mscott

fix checked in

buildid: 2001-04-19-06win98 Navin, Default pop account with an existing or new profile I still see the following: First time you log in with default accounts 'check mail at the start' brings the password dialog for the first account automatically since it is turned on. But now the first time you enter the wrong password there is no feed back in the status bar as'contacting host, sending log information.. blah blah....When I see the password dlg come up the status bar is reading 'Loading Document... and then on giving password and clicking ok the dlg disappears and never comes back. On an existing profile this is misleading because you already have the message displayed in the thread pane that have been previously downloaded and it makes you believe that now you are logged in successfully and every thing is fine. On an new profile no mssgs are retrieved blank thread pane password dlg does not come back untill you click on get message button again. Then we do the right thing in the status bar 'contacting server, sending login info.... and bring back the password dlg till the user provides the correct password This fix will lead to many other pop bugs:( The first time you launch mail and giving wrong password should come back with the password dlg again and again till the user provides the right password. It is not very intuitive for the user to know to click get mssg button to bring back the password dialog. Reopening this bug after all the commentary;) Did not check on other platforms thinking all of them would probably behave the same.

The first time if you enter wrong password and you have no download_on_biff it will fail silently because we do not want to bother the user again. Only if the user wants to download messages again and hits "Get Msg" will the password dialog come up. Now if he/she enters wrong password it should come up again and again until the password entered is correct. Please verify again based on the above comment

Moving to 0.9.1 until we can agree this is or isn't fixed (I don't want it to block the 0.9 release).

Sheela wrote: 2001-04-21 14:25 Opened a new bug for this issue -see bug 77202 *****On an new profile no mssgs are retrieved blank thread pane password dlg does not come back untill you click on get message button again. Then we do the right thing in the status bar 'contacting server, sending login info.... and bring back the password dlg till the user provides the correct password This fix will lead to many other pop bugs:( The first time you launch mail and giving wrong password should come back with the password dlg again and again till the user provides the right password. It is not very intuitive for the user to know to click get mssg button to bring back the password dialog.***** Navin, I disagree that failing silently is a very good thing to do. We should prompt the user if he gave the right information or not. In 4.x we keep prompting the user back with the password dlg untill the user provinded the correct information. Atleast I tried it giving wrong password four times and got the password dlg back. And also I don't mean that we should put this in an infinite loop to keep prompting with the password dlg. Atleast give back the password dlg for 3-4 attempts or some feed back with an alert dlg that his login failed. But not a silent failure. I am not too sure if this bug should be considered as fix at this point.

*** Bug 59945 has been marked as a duplicate of this bug. ***

It sounds like we're getting the password dialog on a biff on startup. In the case where download headers isn't checked we fail silently and when it is checked we keep asking for a password. jglick do you have any opinions on failing silently on the biff password check? I guess ideally you would be told that you typed in something wrong, but I don't think it's as big of a deal as if this didn't happen with get messages.

moving to 0.9.2

If "Check for new mail at startup" is check, pw dialog opens on startup. If wrong pw is provided, dialog should reopen and inform user that incorrect password was supplied. If "Check for new mail at startup" is not checked, no pw dialog opens on startup. User must click "Get Msg" to check for new mail, at that time, pw dialog would open. If wrong pw is provided, dialog should reopen and inform user that incorrect password was supplied.

Based on jglick's comments this bug is fixed. marking fixed.

cannot verify this bug because of some open issues. Need to discuss with jglick.

Reopening this bug, because sheela and I disagree on the fix. I think myself, sheelar and jglick would need to meet to figure out what is the right fix.

ok, I will make it as putterman says in the email "We should probably make it so that it doesn't fail silently and that the user has to press Cancel in order to make the dialog stop coming up. "

This fix will make it so that it keeps prompting the user for a new password if the previous password entered is blank or incorrect, until the server does not close the connection on mozilla. I need review, david.

r=bienvenu - can you get an sr from mscott, since he knows this code more than I do (send him mail)

the fix looks good to me. naving, can you do me a favor and take out the following: if (/* ||MSG_Biff_Master_NikiCallingGetNewMail() */ from the if clause you modified in this patch? sr=mscott

marking pdt+. Please check into the trunk as soon as possible.

@@ -1018,7 +1018,9 @@ } else if (NS_FAILED(rv) || !password || !(* (const char *) password)) { - return Error(POP3_PASSWORD_UNDEFINED); + if (!(* (const char *) password)) + SetFlag(POP3_PASSWORD_FAILED); + return Error(POP3_PASSWORD_UNDEFINED); } nsCAutoString cmd; This defeats the point of the null check for password. If it can never be null here, they you shouldn't have the null check, but if it can be null, then this will crash (right?). And it looks much less scary to use .get() instead of an old-style cast to |(const char *)| that to the quick reader could be a reinterpret-cast.

Nice catch, dbaron. I have removed those lines because they are not needed to fix this bug. ( I was just trying to prompt the user on a blank password.)

a=dbaron for trunk checkin (on behalf of drivers)

fix checked in.

Builds used in verifying above: 2001061807 win98, 2001061808 mac 2001061808 linux Prompts user with the password dialog again when a wrong password is entered. Password dialog does not appear when you click on cancel button. With the blank password and click on ok button. Gives a dlg "Error getting mail password and the password dialog goes away. According to this bug entering the wrong password bring back the password dlg untill user clicks on cancel dialog.