Closed Bug 339690 Opened 18 years ago Closed 17 years ago

Occasionally misses a new message or two during IMAP IDLEs

Categories

(Thunderbird :: General, defect)

x86
Windows XP
defect
Not set
major

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: pete, Assigned: mscott)

Details

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 Firefox/1.0.7
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 Firefox/1.0.7

When Thunderbird is in IDLE mode on an IMAP session and a bunch of new messages arrive in rapid succession in the open folder, one or two of the messages may fail to show up in the display.

Here is a transcript from an IMAP server that exemplifies this:
---------------------------------------------------------------------------------
20 IDLE
+ idling (will time-out in 30 minutes)
* 15 EXISTS
* 15 FETCH (UID 1771 FLAGS (\Draft \Seen))
* 14 FETCH (UID 1770 FLAGS (\Draft \Seen))
* 13 FETCH (UID 1769 FLAGS (\Draft \Seen))
DONE
Event time 358148.562 secs
20 OK IDLE completed (124.937 secs)
21 noop
Event time 358148.609 secs
21 OK NOOP completed (0.000 secs)
22 UID fetch 1772:* (FLAGS)
* 15 FETCH (UID 1771 FLAGS (\Draft \Seen))
Event time 358148.656 secs
22 OK FETCH completed (0.000 secs)
23 UID fetch 1771,1770:1771 (UID RFC822.SIZE FLAGS BODY.PEEK[HEADER.FIELDS (From To Cc Subject Date Message-ID Priority X-Priority References Newsgroups In-Reply-To Content-Type)])
* 14 FETCH (UID 1770 RFC822.SIZE 2826 BODY[HEADER.FIELDS (From To Cc Subject Date Message-ID Priority X-Priority References Newsgroups In-Reply-To Content-Type)] {297}
Message-ID: <600971422.52876@gduz@itl.net.ua>
From: "Amaro Raphael" <xtoslhlg@rome.com>
To: "Aaddict" <aaddict@maclean.com>
Subject: fw : R0LEX repIicas from $l5O
Date: Wed, 14 Sep 2005 16:12:19 -0800
Content-Type: multipart/alternative;
	boundary="AlternativeTexts_--711614477211375758"

 FLAGS (\Draft \Seen))
* 15 FETCH (UID 1771 RFC822.SIZE 25353 BODY[HEADER.FIELDS (From To Cc Subject Date Message-ID Priority X-Priority References Newsgroups In-Reply-To Content-Type)] {286}
Date: Wed, 07 Sep 2005 14:35:19 -0400
To: "" <pete@maclean.com>
From: "American Red Cross" <AmericanRedCross@redcross-email.org>
Subject: Situation Update: A Tragedy Beyond Compare
Content-Type: multipart/alternative;
	boundary="AlternativeTexts_Thunderbolt MultiPart Boundary"

 FLAGS (\Draft \Seen))
Event time 358148.781 secs
23 OK FETCH completed (0.047 secs)
24 IDLE
---------------------------------------------------------------------------------

Note the response "* 13 FETCH (UID 1769 FLAGS (\Draft \Seen))" which notifies Thunderbird about a message with UID 1769.  After completing the IDLE, it FETCHes information about messages 1770 and 1771 but not 1769.  It seems to forget about 1769.

I would also note that the message sequence in "23 UID fetch 1771,1770:1771", while perfectly valid, is rather odd.


Reproducible: Sometimes

Steps to Reproduce:
1. Open an IMAP folder in Thunderbird.
2. Wait until Thunderbird issues an IDLE command.
3. On the server, move a bunch of messages into the folder in question.

Of course this will work only with an IMAP server that supports IDLE and may well be dependent on the particular responses the server sends in IDLE mode.
Actual Results:  
Fewer messages show up in Thunderbird's display than are actually in the IMAP folder.

Expected Results:  
Thunderbird should use IDLE to keep synchronized with the server folder.

Please note that I was unable to verify that this bug persists in the latest daily build because I cannot get the current download for Win32 (that of 30-May-2006) to work at all.
Is this a new problem - not happening in TB 1.5 or in prior trunk builds?
Version: unspecified → Trunk
(In reply to comment #1)
> Is this a new problem - not happening in TB 1.5 or in prior trunk builds?

It is not a new problem in the sense that it happens in 1.5.0.2.  I do not know if it happens with prior builds.  It was reported to me by someone else using 1.5 and I was able to confirm the problem.  I have not seen it in any other version but have no idea whether or not it manifests in other builds.  (As I mentioned in my original report, I did make an attempt to reproduce it using the latest daily build as of that time but could not get said build to work at all.)
Will check and let you know.
Yes, I am confident that this bug is history.  Thank you!
Status: UNCONFIRMED → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.