Closed
Bug 127693
Opened 22 years ago
Closed 22 years ago
automatic "check for new messages" doesn't
Categories
(MailNews Core :: Networking: IMAP, defect)
Tracking
(Not tracked)
VERIFIED
DUPLICATE
of bug 138791
People
(Reporter: dwallach, Assigned: Bienvenu)
Details
Attachments
(3 files)
I seem to have found a regression of bug #70916. I was running Mozilla 0.9.7 and everything worked fine. I upgraded to 0.9.8 and now it doesn't automatically get my new messages. It only seems to check for new messages when I do an operation on my inbox (e.g., read another message). I'm running Mozilla 0.9.8 on Win2000 with a fairly recent U.W. imapd as the backend server.
Assignee | ||
Comment 1•22 years ago
|
||
This isn't a mail db problem. It might be an imap problem, or it might be an account manager/setup problem. Anyway, this works just fine for me on win2k. You have it set to check for new messages on startup, and to check for messages every XX minutes, right? Are you running ssl? And you have remember password turned on?
Component: Mail Database → Networking - IMAP
Reporter | ||
Comment 2•22 years ago
|
||
> You have it set to check for new messages on startup Yup. > and to check for messages every XX minutes, right? Yup, it's set to check every two minutes. > Are you running ssl? Yup. Should I try it with SSL turned off? > And you have remember password turned on? Yup. If I go to the window and hit "Get Msgs", it works without asking for my password. Should I try uninstalling and reinstalling Mozilla? I did the 0.9.7 -> 0.9.8 upgrade in place.
Comment 3•22 years ago
|
||
This problem exists at least when there are two mail clients checking the same account. UW IMAP throws the other one away and Mozilla doesn't recover gracefully. Same thing when the connection is lost and a message is clicked (it won't download the first selected message). That's bug 120106.
Assignee | ||
Comment 4•22 years ago
|
||
try turning off ssl and see if that makes any difference. I've never had to install and uninstall mozilla so I doubt that matters. You could also generate an imap protocol log http://www.mozilla.org/quality/mailnews/mail-troubleshoot.html#imap though my guess is that we're never connecting to the imap server at all.
Reporter | ||
Comment 5•22 years ago
|
||
SSL seems to be the difference. I disabled SSL and now it's working.
Assignee | ||
Comment 6•22 years ago
|
||
Dan, a few questions: do you have a personal cert, and do you have a master security password? I use SSL and biff, but I start up with that inbox selected. After that, biff works fine. I also found that when my certificate had expired, I never got prompted for my master security password, but once I had a valid certificate, I did get prompted for my master security password.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Reporter | ||
Comment 7•22 years ago
|
||
No personal cert, no master password. (P.S. Should I file a bug if replying to the e-mail from bugzilla bounced, and I had to come back to the web page to write this?)
Assignee | ||
Comment 8•22 years ago
|
||
Dan, do you start up with that inbox selected?
Reporter | ||
Comment 9•22 years ago
|
||
Yup, inbox is selected on startup.
Comment 10•22 years ago
|
||
> No personal cert, no master password. that's my set up too (no personal cert, no master password). and this is working for me. I'm using the netscape mail server: * OK judge.mcom.com IMAP4 service (Netscape Messaging Server 4.15 Patch 4 (built Dec 7 2000)) > (P.S. Should I file a bug if replying to the e-mail from bugzilla bounced, and >I had to come back to the web page to write this?) no, that's expected behaviour. to use bugzilla you have to use the website, you can't reply to the mail. dan, can you get a protocol log (http://www.mozilla.org/quality/mailnews/mail- troubleshoot.html#imap) and attach it here to help debug?
Reporter | ||
Comment 11•22 years ago
|
||
Reporter | ||
Comment 12•22 years ago
|
||
Reporter | ||
Comment 13•22 years ago
|
||
These logs show what happens both with SSL on and off. Oddly enough, when I re- enabled the crypto, the auto-refresh worked again. Alas, I should have taken a log before turning the crypto off. I'm guessing this gets written off as unreproducible. Oh well.
Reporter | ||
Comment 14•22 years ago
|
||
But wait, there's more! When I left last night, I happened to have left the e- mail client viewing a folder besides the Inbox. Come back in the morning, and the original buggy behavior has now returned. Do you want another dump?
Assignee | ||
Comment 15•22 years ago
|
||
yes, a log where it didn't work would be useful.
Reporter | ||
Comment 16•22 years ago
|
||
Restarting the browser to turn on the logging, of course, fixed the problem. I suspect the issue occurs only for long-running Mozilla clients. I'm about to go on a business trip. When I get back, on Friday, I'll start Mozilla from scratch and use it over the weekend. No doubt, the log will be insanely big for a weekend of usage, but that should help you isolate the bug.
Assignee | ||
Comment 17•22 years ago
|
||
You suspect it only happens to long running clients? Are you saying that check for new mail works for a while and stops? That's a different story. I thought you were saying that it never worked from startup on. How long is your check for new mail interval? Is it possible that another client is accessing the same inbox? (e.g., you running mozilla on a different machine against the same folder)
Reporter | ||
Comment 18•22 years ago
|
||
Sorry for the confusion. I wasn't sure about it myself. The behavior I seem to be observing is the following: it automatically downloads at first, but then after a period of sufficient inactivity on my part, it stops automatically downloading thereafter. This seems to only occur over SSL, although I might be wrong there as well. I'm adding a new attachment that tries to illustrate this. It's an IMAP log that I've chopped down to (a) make it manageably small and (b) remove some personal e-mail from. It appears that your logs, in some cases, contain entire message bodies. In this case, I started a fresh copy of Mozilla this morning and read mail, then left for lunch. I've marked the break by hand (it's around line 395). I did some fairly significant editing of stuff above there for the reasons cited above. After this, you see what happened when I hit the "Get messages" button. It looks like it's starting over with a fresh IMAP connection. I've also done some censoring below this, again for the reasons cited above (you'll see a place where it says "snip!"). Otherwise, this log shows what happened reasonably well. > How long is your check for new mail interval? 2 minutes. > Is it possible that another client is accessing the same inbox? Nothing else *should* be accessing my mail. Here's the log from imapd. You can see me log into my mail in the morning. I read mail in the morning, at noon, then around 4pm. You can see that new mail was only actually incorporated twice, which is interesting. So, at least in this case, it looks like the auto-update never actually worked. Mar 1 09:30:24 cs.rice.edu imaps[16438]: Authenticated user=dwallach host=localhost [127.0.0.1] Mar 1 09:30:31 cs.rice.edu imaps[16442]: Authenticated user=dwallach host=localhost [127.0.0.1] Mar 1 09:30:58 cs.rice.edu imaps[16438]: Moved 717700 bytes of new mail to /home/dwallach/mbox from /var/mail/dwallach host= localhost [127.0.0.1] Mar 1 09:33:07 cs.rice.edu imaps[16572]: Authenticated user=dwallach host=localhost [127.0.0.1] Mar 1 10:00:38 cs.rice.edu imaps[16442]: Autologout user=dwallach host=localhost [127.0.0.1] Mar 1 11:17:19 cs.rice.edu imaps[16572]: Autologout user=dwallach host=localhost [127.0.0.1] Mar 1 12:13:32 cs.rice.edu imaps[27721]: Authenticated user=dwallach host=localhost [127.0.0.1] Mar 1 12:45:05 cs.rice.edu imaps[27721]: Autologout user=dwallach host=localhost [127.0.0.1] Mar 1 13:38:17 cs.rice.edu imaps[16438]: Autologout user=dwallach host=localhost [127.0.0.1] Mar 1 15:59:19 cs.rice.edu imaps[10942]: Authenticated user=dwallach host=localhost [127.0.0.1] Mar 1 15:59:51 cs.rice.edu imaps[10942]: Moved 1122099 bytes of new mail to /home/dwallach/mbox from /var/mail/dwallach host= localhost [127.0.0.1] Mar 1 16:00:16 cs.rice.edu imaps[10942]: Logout user=dwallach host=localhost [127.0.0.1]
Reporter | ||
Comment 19•22 years ago
|
||
Actually, the log here is missing some stuff. I know I got new messages at least once more than in the morning. Hmmm....
Reporter | ||
Comment 20•22 years ago
|
||
Assignee | ||
Comment 21•22 years ago
|
||
Dan, I looked at the log and I can't really tell where things went wrong. If you have check for new mail every 2 minutes, we should see a NOOP in the log every two minutes. It looks like, from the command counter, that that's been going on at the beginning of the log (it gets up to 300+ commands, and if you didn't do any get new mail, those commands are probably almost all NOOPS). At some point, it looks like the connection gets dropped, and a new connection to the inbox started - but the only thing in the log there is *time passes* so I can't tell what happened to drop the connection. You might also try a newer build - there were some problems with timers that have been fixed recently, and the check for new mail does count on timers to fire (though that's a long shot).
Comment 22•22 years ago
|
||
If this isn't directly IMAP related is there a chance it's bug 134480 ? There the auto-get timer doesn't seem to work with a closed mailnews windows, but leaving it open does keep it running.
Reporter | ||
Comment 23•22 years ago
|
||
Hmm... the window is definitely still there, but it's usually iconified (or hiding somewhere else -- I use a third-party virtual window manager for Windows). FYI, I'm currently running Mozilla 0.9.9 and I'm still having the problem.
Comment 24•22 years ago
|
||
I have this problem with Mozilla 1.0 Release Candidate on W2k. All is fine after start and Mozilla alerts me when new message arrives. After some time (hard to say how much time it takes - hours) it doesn't check new messages any more and I get them only when I select inbox folder. Very nasty.
Assignee | ||
Comment 25•22 years ago
|
||
I've seen this if I leave it running overnight - check for new mail stops. I haven't caught this in the debugger yet, but I'll try. My theory is still that a timer event is getting lost - once that happens, check for new mail will permanently stop, because we rely on the timer firing to set the next timer.
Assignee | ||
Comment 26•22 years ago
|
||
dup of 138791, which has been fixed on the 1.0 branch and the trunk *** This bug has been marked as a duplicate of 138791 ***
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → DUPLICATE
Updated•20 years ago
|
Product: MailNews → Core
Updated•15 years ago
|
Product: Core → MailNews Core
You need to log in
before you can comment on or make changes to this bug.
Description
•