127693 - automatic "check for new messages" doesn't

Status: VERIFIED DUPLICATE of bug 138791

(MailNews Core :: Networking: IMAP, defect)

Description

[Dan Wallach]

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.

Comment 1

[David :Bienvenu]

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?

Comment 2

[Dan Wallach]

> 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

[Ere Maijala (slow)]

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.

Comment 4

[David :Bienvenu]

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.

Comment 5

[Dan Wallach]

SSL seems to be the difference.  I disabled SSL and now it's working.

Comment 6

[David :Bienvenu]

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.

Comment 7

[Dan Wallach]

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?)

Comment 8

[David :Bienvenu]

Dan, do you start up with that inbox selected?

Comment 9

[Dan Wallach]

Yup, inbox is selected on startup.

Comment 10

[(not reading, please use [e-mail] instead)]

> 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?

Comment 11

[Dan Wallach]

Attachment: IMAP log, crypto disabled

Comment 12

[Dan Wallach]

Attachment: IMAP log, crypto enabled

Comment 13

[Dan Wallach]

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.

Comment 14

[Dan Wallach]

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?

Comment 15

[David :Bienvenu]

yes, a log where it didn't work would be useful.

Comment 16

[Dan Wallach]

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.

Comment 17

[David :Bienvenu]

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)

Comment 18

[Dan Wallach]

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]

Comment 19

[Dan Wallach]

Actually, the log here is missing some stuff.  I know I got new messages at 
least once more than in the morning.  Hmmm....

Comment 20

[Dan Wallach]

Attachment: latest log of strange activity

Comment 21

[David :Bienvenu]

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

[Don J. Rude]

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.

Comment 23

[Dan Wallach]

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

[Kaidur Heliste]

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.

Comment 25

[David :Bienvenu]

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.

Comment 26

[David :Bienvenu]

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 ***

Comment 27

[Sheela Ravindran]

verified as dup