15012 - IMAP pseudo-interruption needs to get hooked up

Status: VERIFIED FIXED

(MailNews Core :: Backend, defect, P3)

Description

[David :Bienvenu]

If the user is fetching a large message, and clicks on a second message, we
should pseudo-interrupt the first fetch (stop fetching after the first chunk),
and load the second message.

Comment 1

[David :Bienvenu]

Fixed - to verify, you'd need to click on a really large message, then
quickly click on a small message, and verify that we don't finish downloading
the first message before loading the second message. The protocol log can help
here, or you could use a slow connection.

Comment 2

[Karen Huang]

Used 02-14-16-M14 commercial build:
David, it seems that seamonkey still finish downloading
the first message before loading the second message....
Can you tell me how can I verify on the protocol log?

Comment 3

[Karen Huang]

David, I verified on today's Linux & WinNT 02-21-08-M14 commercial build.
There are no problems for Linux & WinNT anymore...
But for Mac platform, it seems that it still wait for finishing downloading the 
first big attachment message, and then load the small size message later....
I knew that this bug was open for WinNT, but I just double check for Mac 
platform, can you also check for this on Mac? 
--It occurred on Mac at the first time loading message, after the second time 
loading will perform well.

Comment 4

[Karen Huang]

Used 03-07-09-M15 commercial build:
In order to make sure this functionality work appropriately, 
I have tried to use IMAP protocol log to verify this bug:

I got the following 5.0 protocol log when selecting the msg from big size to 
small size:
144[b473680]: nsmail-5:S-INBOX:STREAM:CLOSE: Normal Message End Download Stream
144[b473680]: nsmail-5:S-INBOX:CreateNewLineFromSocket: 14 OK Completed

Shouldn't it be the same as 4.7 protocol log as following?
imapIOthread IMAP stdout:	nsmail-5:S-INBOX:NET:RD: 26 OK Completed	
[Y:\NS\LIB\LIBNET\MKIMAP4.cpp:10000]
imapIOthread IMAP stdout:	nsmail-5:S-INBOX:STREAM:CLOSE: Abort Message  
Download Stream	[Y:\NS\LIB\LIBNET\MKIMAP4.cpp:10000]
mozilla IMAP stdout:	STREAM: Abort Message Download Stream Event	
[Y:\NS\LIB\LIBNET\MKIMAP4.cpp:1317]

I didn't see the "Abort Message" stream from 5.0 protocol log.....
I have tried on slow Mac 150 Mhz & slow Win98 133 Mhz and it seemed that it 
didn't pseudo-interrupt the first fetch everytime...

David, would you please provide more information to me? 
If I didn't record the correct protocol part, 
please provide correct info to me so I can either marke as verified or reopen 
this bug. Thanks.

Comment 5

[David :Bienvenu]

You should see something like:

39[3a58730]: tintin.mcom.com:S-Personal:STREAM:CLOSE: Abort Message  Download 
Stream

Which is what I see when I click on a 6 MB message and then click on a second 
message over a DSL connection. Believe me, the big message has to be VERY VERY 
BIG in order for you to pseudo-interrupt it. The speed of the machine is not 
anywhere near as important as the speed of the network connection to the imap 
server. Also, you should not have clicked on the first message during the 
current run before you try this, because it might come from the memory cache, 
which can't be interrupted.

Comment 6

[David :Bienvenu]

You should also see CONTROL: PSEUDO-Interrupted (as I do in my log when I load a 
6MB message over a slow connection) about a page up from the aborted message 
download.

Comment 7

[Karen Huang]

OK. Thanks. I will try again...

Comment 8

[Karen Huang]

David, would you please attach the 6 MB message on this bug?

Comment 9

[David :Bienvenu]

why don't you send yourself a copy of netscape.exe? I don't want to take up 6MB
of bugzilla space - it's not what's in the message that's important, it's the
total size.

Comment 10

[Karen Huang]

I used dialup connection on 03-07-09-M15 commercial build:

*Test Scenario is: 
Fetching a large message(8MB), and clicks on a second message

*Actual Result is: 
1) Message Body seemed to be stopped displaying message.
2) The meter bar keep processing without stop
3) Even after select the second message, it's not reflect the second message on 
the message body. It just keep displaying fist msg and the meter bar keep 
processing without stop.
4) From IMAP log, I did see the "0[781da0]: nsmail-5:S-INBOX:CONTROL: 
PSEUDO-Interrupted" and "-3758533[308f2e0]: nsmail-5:S-INBOX:STREAM:CLOSE: Abort 
Message  Download Stream", but didn't see it trying to load the second message.
5) I have tried 3 times, and the results are the same....

***Recorded some lines of this IMAP log as following***

-3758533[308f2e0]: nsmail-5:S-INBOX:SendData: 14 UID fetch 370 (XSENDER UID 
RFC822.SIZE BODY[]) -3758533[308f2e0]: nsmail-5:S-INBOX:CreateNewLineFromSocket: 
* 89 FETCH (UID 370 RFC822.SIZE 8848021 XSENDER {0} -3758533[308f2e0]: 
nsmail-5:S-INBOX:CreateNewLineFromSocket:  BODY[] {8848021} -3758533[308f2e0]: 
nsmail-5:S-INBOX:STREAM:OPEN Size: 8848021: Begin Message Download Stream....
............................................

0[781da0]: nsmail-5:S-INBOX:CONTROL: PSEUDO-Interrupted
...................................

-3758533[308f2e0]: nsmail-5:S-INBOX:STREAM:CLOSE: Abort Message  Download Stream

***THE END***

I will attach the whole IMAP log here, 
and will try/investigate this bug again....

Comment 11

[Karen Huang]

I got "software error" when I was trying to attach IMAP log here. 
So I already sent this IMAP log to David.

Comment 12

[David :Bienvenu]

I'm not interrupting layout, I'm just interrupting the download of the imap 
message. If you see the abort message download, then pseudo interruption is 
doing what it is intended to do. Layout will continue to do what it does with 
the data its already been given. I don't know of any way to make that stop.

Comment 13

[Karen Huang]

If this bug only solving the interrupting for the download of the imap 
message, then I need to log the other separate bug for follow-up.....
Anyway, I need to try again.....

Comment 14

[Karen Huang]

Yes. I did try again for the LAN connection in the office and Lab.
All the results are the same as I described before:

I did see the "0[781da0]: nsmail-5:S-INBOX:CONTROL: 
PSEUDO-Interrupted" but did NOT see "-3758533[308f2e0]: 
nsmail-5:S-INBOX:STREAM:CLOSE: Abort Message  Download Stream" displayed....

Like David said that the big message has to be VERY VERY BIG in order for me to 
pseudo-interrupt it, and should be tested over a slow connection....

I already logged the other bug#31191 for keep track other problems 
(interrupting layout problems)
Finally, marking as verified for this bug!