93537 - GetMsg on IMAP repeats download of the message, outliner problems when deleting phantom messages.

Status: VERIFIED FIXED

(MailNews Core :: Networking: IMAP, defect)

Description

[[e-mail] (gone - use [e-mail] instead)]

Build ID:  2001-08-03-03, Windows 2000.

Summary:  GetMsg on IMAP repeats download of the message, deleting the repeats
cause s bad row counts in outliner.

Bear with me, the steps to reproduce aren't 100% at this time. (needs filing
though, multiple people have seen this)

Steps to Reproduce:

1.  Delete a message in your IMAP inbox.
2.  Click GetMsg (I have new mail notification turned on, maybe part of it)
3.  Click GetMsg again, note sometimes you can do this infinitely and receives
DUPS of that same msg.
4.  Try to delete one or multiples of this message.

Expected Results:

You should receive the original message.  

Actual Results:

You can infinitely GetMsg on this message and get DUPS all over your Inbox. 
Also, deleting these messages causes outliner to get confused (bad row counts)

Comment 1

[David :Bienvenu]

I believe this is an imap problem. This might have to do with some changes I
made to the uid+flags array handling code, though I have not seen this problem.

Comment 2

[David :Bienvenu]

what's "this message"? is it the one you just deleted, or a new message that
happened to arrive?

Comment 3

[David :Bienvenu]

I can't reproduce this - can you attach an imap protocol log, please?

Comment 4

[[e-mail] (gone - use [e-mail] instead)]

Attachment: Here ya go ;-)

Comment 5

[David :Bienvenu]

it's definitely an imap problem (or a view problem)- that's a very weird log.
Even when you deleted the message, it tried to move the same message to the
trash about 20 times, as if the selection had 20 copies of the same thing in it.
CC'ing Seth and Navin in case that rings any bells.

Comment 6

[[e-mail] (gone - use [e-mail] instead)]

Bienvenu, to address your comment, "Even when you deleted the message, it tried
to move the same message to the
trash about 20 times, as if the selection had 20 copies of the same thing in
it", that was when I had selected about 20 of the duplicate messages and tried
to delete them (I believe the original message was already in the trash when I
had attempted to delete the 20 duplicates, thus causing that bad row count
problem.) 

Also, this happened very easily for me with:
1. biff on
2. migrated 4.78 profile
3. logged into IMAP, did GetMsg, read one, deleted it, did GetMsg again, got
another one, read it and then did GetMsg again.

Comment 7

[[e-mail] (gone - use [e-mail] instead)]

FWIW, I've seen this for the past 2 days or maybe 3, it's just that I couldn't
ever reproduce it, so I didn't file ;-(

Comment 8

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

*** Bug 93532 has been marked as a duplicate of this bug. ***

Comment 9

[David :Bienvenu]

I'm sure this is my fault, but it is weird that when we ask the server for 44919:*

it keeps giving us 44918. We should be ignoring that since we already have it,
but why is the server doing that?

Comment 10

[Navin Gupta]

I have seen this once on linux, could be a server glitch.

Comment 11

[Karen Huang]

I saw this problem in front of Stephen's machine
This should be fixed for next release.
Nominating nsBranch for the keywords even though I cannot reproduce this 
problem yet by myself yet......

Comment 12

[Karen Huang]

QA-> me.

Comment 13

[John G. Myers]

Per the IMAP spec, * in that context means the highest UID in the mailbox, which 
is 44918.  Ranges are not order sensitive, so 44919:44918 means the same as 
44918:44919.  Since there is no extant message with UID 44919, this means the 
same thing as just 44918.

Comment 14

[David :Bienvenu]

OK, I can reproduce this easily if I delete a message, do a compact folder, and
then do a get new mail. By default, we only compact a folder if there are 20
deleted messages or so, so otherwise, this wouldn't happen very often (at least
for me).

Comment 15

[David :Bienvenu]

Attachment: proposed fix

Comment 16

[David :Bienvenu]

I screwed up my last patch and removed the wrong line from this loop (I removed
the line adjusting the flags when I meant to remove the line adjusting the uids
- I screwed this up right before I checked in trying to undo some changes in the
editor that I didn't need :-( )

Comment 17

[David :Bienvenu]

fix checked in.

Comment 18

[Karen Huang]

I can reproduce this problem on 08-03-06-trunk build 
by following David's steps.

By using 08-14-06-trunk build.
After delete msg, compact folder and get msg, those repeat msgs for the last msg 
on the thread pane are disappear now. Marking as verified.
Stephen, please reopen this bug if problem is still existing on your system.