2003091704 trunk After some period of time, Mozilla stops retrieving new mail. Pressing the "Get new messages" button has no effect (Moz doesn't even try - no network activity). Restarting Mozilla is required. Tried a POP3 log, but it shows nothing unusual. This has proven difficult to reproduce reliably, but it does happen repeatedly with the 916 and 917 builds. I am working on reliably reproducing it, but wanted to document it while it was "fresh".

I have tried the following theories with no luck so far: 1) That after X number of biffs, Moz just stops. The number of biffs before it stops is random. 2) That receiving a junk mail triggered the problem, but it did not happen after I received another junk message. 3) That, somehow, it was related to form submission (long story), but that isn't it either.

Here is a POP3 log where biff stopped working for over an hour and "Get new mail" didn't work either. IP address and path have been obscured, but the rest is exactly as it was logged.

*** This bug has been marked as a duplicate of 219449 ***

I don't think this is a dup - this bug is about mail retrieval stopping after some period of time - the other bug is about it not working at all, I believe.

Ok. Just that once biff stops working, so does manual "Get new messages"

I have seen this on my laptop multiple times. I am using the XP 2003091704 build. [I don't use Mozilla mail on the linux boxes... I have never put VMware on the laptop... I use it for compile/testing Wind... apps, Linux for development, etc.] I see the problem after disconnecting the network (which changing rooms) and/or after leaving Mozilla up overnight. The workaround is stopping Mozilla (all parts) and restarting. Popping is then fine. -Jeff

This is making Mozilla usage difficult. It stops on a regular basis without any indication. The only way to figure out that it has stopped is to think "gee, I haven't received any mail for a while"

For anyone else looking at this, testing has confirmed that this regressed between the 091510 trunk and 091604 trunk.

Nominating for blocking 1.5. I don't think releasing a version onto the public with POP3 broken is such a good thing.

Er, Jerry, you see this in the trunk, yes? If you want this as a blocker for 1.5, did you test the 1.5 branch builds, resp. the RCs?

Er, oops. No. I forgot that they already cut the 1.5 branch. Changing to 1.6.

Jerry and I tracked this down to the nsMsgIncomingServer object thinking it was still busy, for some reason. So either we set that flag and then didn't run a url at all, or set it and ran a url but didn't clear the flag when the url was done.

the reason we think the server is busy is that we're not getting the OnStopRequest notification. I added logging when we start a url, and when we get the on stop request: here's the tail of the log, just before the problem happens: 0[265b58]: POP3: Entering state: 15 0[265b58]: POP3: Entering state: 22 0[265b58]: SEND: QUIT 0[265b58]: Entering NET_ProcessPop3 56 0[265b58]: POP3: Entering state: 3 0[265b58]: RECV: +OK nvsvr1.nventure.com POP3 server closing connection 0[265b58]: POP3: Entering state: 41 0[265b58]: POP3: Entering state: 23 0[265b58]: POP3: Entering state: 25 0[265b58]: in on stop request 0[265b58]: WARNING: nsTimeoutImpl::Release() proceeding without context., file c:/six5/mozilla/dom/src/base/nsGlobalWindow.cpp, line 5182 0[265b58]: loading pop3 url 0[265b58]: WARNING: NS_ENSURE_TRUE(mListeners) failed, file c:/six5/mozilla/mailnews/addrbook/src/nsAddrBookSession.cpp, line 94 0[265b58]: WARNING: NS_ENSURE_TRUE(NS_SUCCEEDED(rv)) failed, file c:/six5/mozilla/mailnews/addrbook/src/nsAbMDBDirectory.cpp, line 187 0[265b58]: WARNING: NS_ENSURE_TRUE(NS_SUCCEEDED(rv)) failed, file c:/six5/mozilla/mailnews/addrbook/src/nsAbMDBDirectory.cpp, line 861 0[265b58]: WARNING: NS_ENSURE_TRUE(NS_SUCCEEDED(rv)) failed, file c:/six5/mozilla/mailnews/addrbook/src/nsAddrDatabase.cpp, line 299 0[265b58]: WARNING: Should not try to set the focus on a disabled window, file c:/six5/mozilla/dom/src/base/nsGlobalWindow.cpp, line 2460 0[265b58]: WARNING: Should not try to set the focus on a disabled window, file c:/six5/mozilla/dom/src/base/nsGlobalWindow.cpp, line 2460 0[265b58]: WARNING: Should not try to set the focus on a disabled window, file c:/six5/mozilla/dom/src/base/nsGlobalWindow.cpp, line 2460 0[265b58]: WARNING: Should not try to set the focus on a disabled window, file c:/six5/mozilla/dom/src/base/nsGlobalWindow.cpp, line 2460 0[265b58]: WARNING: Should not try to set the focus on a disabled window, file c:/six5/mozilla/dom/src/base/nsGlobalWindow.cpp, line 2460 0[265b58]: WARNING: empty damage rect: update caller to avoid fcn call overhead, file c:/six5/mozilla/layout/html/base/src/nsFrame.cpp, line 2541 0[265b58]: WARNING: empty damage rect: update caller to avoid fcn call overhead, file c:/six5/mozilla/layout/html/base/src/nsFrame.cpp, line 2541 Notice that we load the pop url, and we never get into the pop3 protocol state machine, and we never get an onStopRequest. I see scattered instances of the WARNINGS throughout the log so I don't know if they're involved or not. I tend to doubt it.

Updating summary. If Mozilla attempts to connect to a POP3 server, and the connection to the server fails, Mozilla refuses to ever get mail again until it is restarted.

dup *** This bug has been marked as a duplicate of 219376 ***

I am seeing this problem again in 2003112108 builds.

REOPEN: per last comment. Also, I'm not entirely clear, based on the problem description, that this is indeed caused by bug 219376.

is this still happening with 1.6 final or tbird .4?

This does seem to happen on 1.6 final. Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113

This does happen for me on 1.6 final too. Very common if Norton Antivirus installed. NAV will pop up dialog when infected email arrives (telling user about it, requiring you to hit "close" to clear dialog). If user is not there, it causes some timeout to occur, and all popping stops (as above).

I get this (or a very similar) bug on Mozilla 1.7.1 as well.

I sniffeed the packets leading to Mozilla stopping mailcheck of a particular account. Not reporting SYNs and ACKs the conversation is: +OK POP3 d1o902.telia.com v7.61 server ready -ERR Autologout; idle for too long

> If Mozilla attempts to connect to a POP3 server, and the connection to the > server fails, Mozilla refuses to ever get mail again until it is restarted. I have seen this behaviour under Linux as well (Fedora 2/3 and Mandrake 8) with multiple versions of Mozilla and Thunderbird. Right now I am running Thunderbird 0.9 (20041127) on Fedora core 3 final. When the problem occurs, I can press "get mail" but the program won't actually attempt to fetch mail until after I restart it. In my case, I think the problem is usually related to switching my laptop between different networks. Under certain circumstances (to do with VPN tunnels) my computer can resolve an IP address for my mail server but cannot actually reach it, so thunderbird tries to contact the server but times out. If I leave thunderbird online in this configuration, trying to contact the server automatically every 5 minutes, it _sometimes_ gets into the state where it stops trying to get mail even when asked to. However, I have never figured out a 100% repeatable way to reproduce the problem. On other occasions, thunderbird continues fetching mail as normal once the route to the mail server is re-established - in fact this is happening most of the time today when I try to reproduce the problem... If I remember correctly (sorry to be vague), I have also seen the problem occur just due to "ordinary network glitches" between the mail server and client, without any reconfiguring of VPN tunnels, so I don't think it's due to one particular "weird" setup. Please let me know if I can provide more information. I should note that I'm not an expert in this stuff, just a relatively knowledgeable end user.

Is this a state that can be reset by toggling the "offline-online" button? In some cases, that solved brower problems in necko, temporarily.

> Is this a state that can be reset by toggling the "offline-online" button? In > some cases, that solved brower problems in necko, temporarily. I think I tried that and it did not solve the problem (just now my laptop is in for repair or I would try again). However, may last comment (#24) may have been too hasty. It is true that under the circumstances I described, thunderbird sometimes stops trying to fetch mail - but I discovered that it (at least) sometimes reverts to normal if I leave it long enough after the route to the POP server is restored. I believe that when this problem occured in older versions of Mozilla (eg. 1.4 on Linux), the program never came back to the normal state of being able to fetch mail until restarted (I was experiencing the problem for some time before trying Thunderbird 0.9). Having waited a few minutes, I therefore originally concluded that Thunderbird was doing the same thing. Sorry if my previous comment was misleading - but it would still be great if, when Thunderbird gets into this state, pressing "get mail" would make it try to get messages again immediately instead of having to wait a few minutes.

> Is this a state that can be reset by toggling the "offline-online" button? In > some cases, that solved brower problems in necko, temporarily. I have tried with several versions of mozilla, and this operation fixes web connection lost, but does not fix pop connection lost. This bug is a major bug. It makes thunderbid impossible to use for professional users, or any serious user. It may be complex to track, but in my opinion, it should have a high severity and priority.

-> default owners.

sorry for the spam. making bugzilla reflect reality as I'm not working on these bugs. filter on FOOBARCHEESE to remove these in bulk.

For what it's worth, I don't see this bug any more. I'm not sure when it got fixed, or what the culprit may have been (there were server changes at my ISP since my last comment). Using Mozilla version 1.7.13: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.13) Gecko/20060414

do others agree this problem is gone?

=> WFM per comment 30

I have not seen this same behaviour with recent versions of Thunderbird, though I am now using IMAP rather than POP. Sometimes when Thunderbird has been unable to retrieve mail for a while (eg. due to a lost VPN connection) the "Get Mail" button seems to do nothing for a few minutes after the connection is restored, but eventually (within maybe 5 minutes) it starts working again as normal.