User-Agent: Mozilla/5.0 (Windows 2002 Government Server Edition; en-US) Gecko/2002110408 Build Identifier: Mozilla/5.0 (Windows 2002 Government Server Edition; en-US) Gecko/2002110408 This bug was introduced when Bug 160425 was fixed. The old behavior in regards to this issue was that password manager would forget the password and ask for it again (silly). But now an error message (alert) appears saying the error and what the mail server said. After the user clicks OK, Mail tries to contact the server again, or try the PASS command (whichever the case). Since nothing has changed (most likely), the connection fails, and another alert is displayed. This results in an endless loop if the server is unavailable or the PASS command fails everytime. I suggest after 2 or 3 fails, Mail says "I give up" or something and stops trying to connect. Reproducible: Always Steps to Reproduce: Expected Results: Mail tries say 2 or 3 times, says "I give up" and then stops trying to connect.
similar: bug 177900
*** Bug 177900 has been marked as a duplicate of this bug. ***
Reporter, remember to include "steps to reproduce", as they are often the most helpful parts of reporting the bug. :) I've included comments from bug 177900 (marked a duplicate) which includes additional information and steps to reproduce. ------- Additional Comments from Bug 177900 ------- : This alert if correct, however, when I dismiss the alert box by clicking OK, it reappears. This behavoir has continued over 10 times before I terminated the application. The only server settings set are "Use Secure Connection" and "Leave Messages on Server" Reproducible: Always Steps to Reproduce: 1."Get MSgs"->"Get All New Messages" 2.Until END-OF-TIME 3. dismiss the alert box by clicking OK 4.Loop Actual Results: I got bored of clicking OK and killed Mozilla Expected Results: Dismissed the alert box ONCE
WFM, Linux, 4 day old CVS. My mailserver was down for maintainance yesterday, and I only had to dismiss the prompt once. It reappeared only every 10th minute - as expected, since it's the interval i've set in prefs. No fancy setup - plain POP.
I got the information regarding the unavailablity/endless loop from bug 160425. I just tested that now, and I only got one alert, as described in comment 4. This bug therefore seems to be limited to when the PASS command fails. Examples of this could be if the account was temporarily "inactivated" (which is a feature on some mailservers), or for other reasons I'm not aware of. In any case, I updated the summary to reflect that this bug is *ONLY* reproducable if the PASS command fails. Thanks!
Summary: If mailserver unavailable or PASS command fails, endless alert loop ensues → If PASS command fails while talking to mailserver, endless alert loop ensues
re comment 5: Please add info about which build ID you were able to reproduce the bug with this time.
I can reproduce this on 1.2.1 Win32. The latest nightly I downloaded crashes with GKCONTENT.dll error, but I know a week or so ago I could reproduce this problem on the latest nightly.
COnfirm this bug on 1.2.1 and latest nightly build. The only solution is to kill Mozilla! This bug has big impact on user experience - mozilla mail is... unusable when your pop3 server is off. No way to rid of the annoying modal pop-up...
*** Bug 192535 has been marked as a duplicate of this bug. ***
*** Bug 193269 has been marked as a duplicate of this bug. ***
The bug can be reproduced by changing the pop password on the server. My mail server automatically asks for a new password after some time, so i had to change it and now i can't use Mozilla Mail anymore because of this endless dialog loop. Tested on Mozilla 1.3b Windows XP Is it possible to change the Pop password somewhere else in Mozilla, in previous version Mozilla asked for a new password so i don't know how to change it. I think this would be a useful workaround if there's another way to change it.
Hit this today with my AT&T POP mail, the alert said postffice being serviced. Got out of it by hitting enter then *immediately* closing the mailnews window. Of course I can't read my AT&T mail now, but hopefully this goes away once the server is up again. Secure connection when available, use password manager to store passwords, commercial 1.3b bits, win2k. komtur & others, you can clear your remembered passwords from prefs: Edit > Preferences... > Privacy & Security > Passwords > Manage Stored Passwords, then find the entry for your mailserver, and remove it. Next time MailNews needs a password it will ask it from you.
Another reason this can occur: My University's mailserver has a two-minute "timeout" set on it. If I try to check mail within two minutes of the last check, Mozilla will correctly return the error message that the PASS command failed and I must wait x seconds to try again. However, when I attempt to dismiss the window with the "OK" button or close window box, Mozilla immediately attempts to check mail again, resulting in the error message. Rinse, repeat, for the entire timeout period. I either need to force Mozilla to quit or leave the error window up until the timeout period has expired. This can occur for varying reasons despite my mail check frequency being set to every 10 minutes. Steps to reproduce: attempt to check mail within the timeout period on an appropriate mail server.
I have a similar situation: I change my domain password, and mozilla gives me the PASS failed until I get locked out of my account, and then gives me something like "your account has been locked...blah", over and over. setup: win2k mozilla 1.3final
*** Bug 199077 has been marked as a duplicate of this bug. ***
I concur that my reported Bug 202898 is a duplicate of this bug, and of Bug 182362, but I like my summary better, because it is more likely someone will find it by that summary in a search.
Jon, that's fine. Can you suggest a better (merged) summary for this bug ?
I suggest the summary I used in Bug 202898, because it contains the words I used in searching before reporting the bug (and got "Zarro Boogs"): Mail server authentication failure alert repeats disabling further action
*** Bug 202898 has been marked as a duplicate of this bug. ***
I'm sticking with the current summary, because although both summaries describe the problem, the summary on this bug seems to me to describe the *cause* of the problem, whereas Bug 202898's summary seems to describe the *effect* of the problem.
Summary: If PASS command fails while talking to mailserver, endless alert loop ensues → If PASS command fails while talking to mailserver, endless alert (dialog box) loop ensues
*** Bug 201021 has been marked as a duplicate of this bug. ***
*** Bug 185682 has been marked as a duplicate of this bug. ***
This situation (PASS command fails message) can occur when a mailserver is down for maintenance or because of some kind of failure, which can last for hours. This is a common problem with some servers, so this bug gets my vote. The correct behaviour is not to discard the stored password, as this will still be valid when the server comes back to life. I am running Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030529 My suggested solution: replace the current dialog by one with Retry and Cancel buttons, perhaps also one allowing the user to enter a new password.
*** Bug 210013 has been marked as a duplicate of this bug. ***
I can reproduce this bug on Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5a) Gecko/20030629 Another problem with the reapearing alert is that it blocks other mozilla windows. If you have open both Browser and Mail windows, showing of the content of the web pages in Browser window is susspended until the alert dialog in Mail window is closes. Step to reproduce: 1. Open Browser window, go to page that loads long 2. Open Mail window with account that causes alert dialog to appear 3. Wait until alert dialog appears, do not close it but look at Browser window Expected results: Browser continues in loading/showing the web page Current results: Browser window waits for the Mail alert dialog (loading is suspended) Should I report this as a separate bug?
Closing this bug as fixed because it of backing out bug 160425's fix. See comment #25 and following discussion in that bug.
Status: NEW → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.