Used 03-07-09-M15 commercial build: Need to have interrupting/stop for Layout. This bug is related to bug#15012. Overview: Seamonkey already had interrupting for the download of the imap message.(pseudo interruption is doing what it is intended to do - see bug#15012) Layout should continue to do what it does with the data its already been given. We should have a way to make that stop. *Test Scenario is: Fetching a large message(8MB), and clicks on a second message *Actual Results are: 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 by using the slow connection, and the results are the same.... Expected results: After we pseudo-interrupt the first fetch (stop fetching after the first chunk), the meter bar should stop and after select the second message, it's should reflect the second message on the message body.

David?

No, I'm not convinced there's a bug here. I've never seen this, and I've spent many hours trying to reproduce Karen's problem.

I have spent many hours too for testing both from slow & LAN connection: With downloading this large 8MB message: 1) This very large message can be only pseudo-interrupted by using slow connection (ex: dialup connection), ABORT MESSAGE displayed from the log but just ending here (it didn't fetch the second message when interrupting to select the second message....shouldn't the log continue same as 4.7 as following...?) 2) This very large message cannot be stopped from LAN, ABORT MESSAGE didn't display and it didn't fetch the second message either when interrupting to select the second message. Following is the IMAP log from 4.7: (Shouldn't the log continue after "Abort Message" as 4.7 for fetching the second message...?) ---------------------------------------------------------------------------- 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] mozilla IMAP stdout: URL: Loading IMAP://nsmail-5?fetch>UID>/INBOX>348 [Y:\NS\LIB\LIBNET\MKIMAP4.cpp:10691] imapIOthread IMAP stdout: nsmail-5:S-INBOX:NET:WR: 27 UID fetch 348 (XSENDER UID RFC822.SIZE BODY[]) [Y:\NS\LIB\LIBNET\MKIMAP4.cpp:10000] imapIOthread IMAP stdout: nsmail-5:S-INBOX:NET:RD: * 73 FETCH (UID 348 RFC822.SIZE 1046 XSENDER {0} [Y:\NS\LIB\LIBNET\MKIMAP4.cpp:10000] imapIOthread IMAP stdout: nsmail-5:S-INBOX:NET:RD: BODY[] {1046} [Y:\NS\LIB\LIBNET\MKIMAP4.cpp:10000] imapIOthread IMAP stdout: nsmail-5:S-INBOX:STREAM:OPEN Size: 1046: Begin Message Download Stream [Y:\NS\LIB\LIBNET\MKIMAP4.cpp:10000] mozilla IMAP stdout: STREAM: Begin Message Download Stream Event [Y:\NS\LIB\LIBNET\MKIMAP4.cpp:949] imapIOthread IMAP stdout: nsmail-5:S-INBOX:NET:RD: Return-Path: <qatest30@netscape.com> [Y:\NS\LIB\LIBNET\MKIMAP4.cpp:10000] imapIOthread IMAP stdout: nsmail-5:S-INBOX:NET:RD: Received: from netscape.com ([205.217.237.47]) by [Y:\NS\LIB\LIBNET\MKIMAP4.cpp:10000] imapIOthread IMAP stdout: nsmail-5:S-INBOX:NET:RD: tintin.mcom.com (Netscape Messaging Server 4.1) with ESMTP id [Y:\NS\LIB\LIBNET\MKIMAP4.cpp:10000] imapIOthread IMAP stdout: nsmail-5:S-INBOX:NET:RD: FQ5GV500.9RH for <qatest30@tintin.mcom.com>; Fri, 18 Feb 2000 [Y:\NS\LIB\LIBNET\MKIMAP4.cpp:10000] imapIOthread IMAP stdout: nsmail-5:S-INBOX:NET:RD: 15:49:53 -0800 [Y:\NS\LIB\LIBNET\MKIMAP4.cpp:10000] imapIOthread IMAP stdout: nsmail-5:S-INBOX:NET:RD: Received: from poisonoak.mcom.com (poisonoak.mcom.com [208.12.41.80]) [Y:\NS\LIB\LIBNET\MKIMAP4.cpp:10000] imapIOthread IMAP stdout: nsmail-5:S-INBOX:NET:RD: by netscape.com (8.8.5/8.8.5) with ESMTP id PAA22512 [Y:\NS\LIB\LIBNET\MKIMAP4.cpp:10000] imapIOthread IMAP stdout: nsmail-5:S-INBOX:NET:RD: for <qatest30@netscape.com>; Fri, 18 Feb 2000 15:47:56 -0800 (PST) [Y:\NS\LIB\LIBNET\MKIMAP4.cpp:10000] imapIOthread IMAP stdout: nsmail-5:S-INBOX:NET:RD: Received: from netscape.com (h-208-12-40-221.mcom.com [208.12.40.221]) by poisonoak.mcom.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.1960.3) [Y:\NS\LIB\LIBNET\MKIMAP4.cpp:10000] imapIOthread IMAP stdout: nsmail-5:S-INBOX:NET:RD: id 1FGVC3YR; Fri, 18 Feb 2000 15:37:00 -0800 [Y:\NS\LIB\LIBNET\MKIMAP4.cpp:10000] imapIOthread IMAP stdout: nsmail-5:S-INBOX:NET:RD: Message-ID: <38ADDA8A.2050900@netscape.com> [Y:\NS\LIB\LIBNET\MKIMAP4.cpp:10000] imapIOthread IMAP stdout: nsmail-5:S-INBOX:NET:RD: Date: Fri, 18 Feb 2000 15:49:30 -0800 [Y:\NS\LIB\LIBNET\MKIMAP4.cpp:10000] imapIOthread IMAP stdout: nsmail-5:S-INBOX:NET:RD: From: qatest30 <qatest30@netscape.com> [Y:\NS\LIB\LIBNET\MKIMAP4.cpp:10000] imapIOthread IMAP stdout: nsmail-5:S-INBOX:NET:RD: User-Agent: Netscape 5.0 [Y:\NS\LIB\LIBNET\MKIMAP4.cpp:10000] imapIOthread IMAP stdout: nsmail-5:S-INBOX:NET:RD: X-Accept-Language: en [Y:\NS\LIB\LIBNET\MKIMAP4.cpp:10000] imapIOthread IMAP stdout: nsmail-5:S-INBOX:NET:RD: MIME-Version: 1.0 [Y:\NS\LIB\LIBNET\MKIMAP4.cpp:10000] imapIOthread IMAP stdout: nsmail-5:S-INBOX:NET:RD: To: qa test30 <qatest30@netscape.com> [Y:\NS\LIB\LIBNET\MKIMAP4.cpp:10000] imapIOthread IMAP stdout: nsmail-5:S-INBOX:NET:RD: Subject: send [Y:\NS\LIB\LIBNET\MKIMAP4.cpp:10000] imapIOthread IMAP stdout: nsmail-5:S-INBOX:NET:RD: Content-Type: text/html; charset=us-ascii [Y:\NS\LIB\LIBNET\MKIMAP4.cpp:10000] imapIOthread IMAP stdout: nsmail-5:S-INBOX:NET:RD: Content-Transfer-Encoding: 7bit [Y:\NS\LIB\LIBNET\MKIMAP4.cpp:10000] imapIOthread IMAP stdout: nsmail-5:S-INBOX:NET:RD: [Y:\NS\LIB\LIBNET\MKIMAP4.cpp:10000] imapIOthread IMAP stdout: nsmail-5:S-INBOX:NET:RD: <html><head></head> [Y:\NS\LIB\LIBNET\MKIMAP4.cpp:10000] imapIOthread IMAP stdout: nsmail-5:S-INBOX:NET:RD: <body>send </body> [Y:\NS\LIB\LIBNET\MKIMAP4.cpp:10000] imapIOthread IMAP stdout: nsmail-5:S-INBOX:NET:RD: </html> [Y:\NS\LIB\LIBNET\MKIMAP4.cpp:10000] imapIOthread IMAP stdout: nsmail-5:S-INBOX:NET:RD: [Y:\NS\LIB\LIBNET\MKIMAP4.cpp:10000] imapIOthread IMAP stdout: nsmail-5:S-INBOX:NET:RD: ) [Y:\NS\LIB\LIBNET\MKIMAP4.cpp:10000] imapIOthread IMAP stdout: nsmail-5:S-INBOX:STREAM:CLOSE: Normal Message End Download Stream [Y:\NS\LIB\LIBNET\MKIMAP4.cpp:10000] mozilla IMAP stdout: STREAM: Normal End Message Download Stream Event [Y:\NS\LIB\LIBNET\MKIMAP4.cpp:1281] imapIOthread IMAP stdout: nsmail-5:S-INBOX:NET:RD: 27 OK Completed --------------------------------------------------------------------------- David, please let me know if you still cannot reproduce this problem .... I can eith show you in my cubicle for LAN connection, or you can try from dialup connection from your home, too.

can we leave this alone until I have some more time to concentrate on IMAP? I have lots of other stuff to worry about at the moment.

I know David are not asking me.... But, I agree with David, I log this bug is just keep tracking this problem. We do have lots of other stuff to worry about at the moment...

can you try this again, Karen? Thanks!

I tried LAN connection in office and the actual results are the same as before: 1) Message Body seemed to be stopped displaying message. 2) The meter bar keep processing without stop 3) After select the second message, it did not reflect the second message on the message body. (It just keep displaying first msg and the meter bar keep processing without stop) 4) From IMAP log, I did see: "0[7e1bf0]: nsmail-5:S-INBOX:CONTROL: PSEUDO-Interrupted" 5)Did NOT see "Abort Message Download Stream" displaying (slow connection/dialup will display the "Abort Message", but LAN did NOT) 6)Didn't see it trying to load the second message (Please see the attached IMAP log file, it just stop at the "PSEUDO-Interrupted" -- not trying to load the second message. I will try on slow connection (dialup) at home tonight.....

I already sent the IMAP log to David since I still got the "software error" when trying to attach IMAP log here. (I may need to log another bug for Bugzilla problem....)

moving to m17

I tried slow connection (dialup connection) at home and the actual results are the same as before: 1) Message Body seemed to be stopped displaying message. 2) The meter bar keep processing without stop 3) After select the second message, it did not reflect the second message on the message body. (It just keep displaying first msg and the meter bar keep processing without stop) 4) From IMAP log, I did see: "0[7e1bf0]: nsmail-5:S-INBOX:CONTROL: PSEUDO-Interrupted" 5)"Abort Message Download Stream" also displayed in the end of the IMAP log (slow connection/dialup displayed the "Abort Message", but LAN did NOT) 6)Didn't see it trying to load the second message (IMAP log file stop and end at the "Abort Message Download Stream" --did not try to load the second message)

try again with tomorrow's build. I bet you don't have the fetch_by_chunks preference set (it's a hidden pref). I've changed the default to true.

Used today's windows build 04-05-09-M15 commercial build: Wow! I can see the improvement now... The expected results are exactly the same as I described: After we pseudo-interrupt the first fetch (stop fetching after the first chunk), the meter bar stop and after select the second message, it's reflect the second message on the message body now. Copied Netscape6 IMAP log here...Yes. It did fetch the second message now.... ---------------------------------------------------------------------------- 222[3016c80]: nsmail-5:S-INBOX:STREAM:CLOSE: Abort Message Download Stream 222[3016c80]: nsmail-5:S-INBOX:SendData: 47 UID fetch 538 (XSENDER UID RFC822.SIZE BODY[]) 222[3016c80]: nsmail-5:S-INBOX:CreateNewLineFromSocket: * 4 FETCH (UID 538 RFC822.SIZE 1013 XSENDER {0} 222[3016c80]: nsmail-5:S-INBOX:CreateNewLineFromSocket: BODY[] {1013} 222[3016c80]: nsmail-5:S-INBOX:STREAM:OPEN Size: 1013: Begin Message Download Stream 222[3016c80]: nsmail-5:S-INBOX:CreateNewLineFromSocket: Return-Path: <qatest30@netscape.com> 222[3016c80]: nsmail-5:S-INBOX:CreateNewLineFromSocket: Received: from netscape.com ([208.12.40.221]) by tintin.mcom.com 222[3016c80]: nsmail-5:S-INBOX:CreateNewLineFromSocket: (Netscape Messaging Server 4.1) with ESMTP id FSKHZB00.LA0 for 222[3016c80]: nsmail-5:S-INBOX:CreateNewLineFromSocket: <qatest30@netscape.com>; Wed, 5 Apr 2000 16:45:11 -0700 222[3016c80]: nsmail-5:S-INBOX:CreateNewLineFromSocket: Message-ID: <38EBCFE5.5090602@netscape.com> 222[3016c80]: nsmail-5:S-INBOX:CreateNewLineFromSocket: Date: Wed, 05 Apr 2000 16:44:37 -0700 222[3016c80]: nsmail-5:S-INBOX:CreateNewLineFromSocket: From: qatest30@netscape.com (qa test30) 222[3016c80]: nsmail-5:S-INBOX:CreateNewLineFromSocket: User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; m14) Netscape6/6.0b1 222[3016c80]: nsmail-5:S-INBOX:CreateNewLineFromSocket: X-Accept-Language: en 222[3016c80]: nsmail-5:S-INBOX:CreateNewLineFromSocket: MIME-Version: 1.0 222[3016c80]: nsmail-5:S-INBOX:CreateNewLineFromSocket: To: qa test30 <qatest30@netscape.com> 222[3016c80]: nsmail-5:S-INBOX:CreateNewLineFromSocket: Subject: sadsadasd 222[3016c80]: nsmail-5:S-INBOX:CreateNewLineFromSocket: Content-Type: multipart/alternative; 222[3016c80]: nsmail-5:S-INBOX:CreateNewLineFromSocket: boundary="------------090108060605030301020609" 222[3016c80]: nsmail-5:S-INBOX:CreateNewLineFromSocket: 222[3016c80]: nsmail-5:S-INBOX:CreateNewLineFromSocket: 222[3016c80]: nsmail-5:S-INBOX:CreateNewLineFromSocket: --------------090108060605030301020609 222[3016c80]: nsmail-5:S-INBOX:CreateNewLineFromSocket: Content-Type: text/plain; charset=us-ascii; format=flowed 222[3016c80]: nsmail-5:S-INBOX:CreateNewLineFromSocket: Content-Transfer-Encoding: 7bit 222[3016c80]: nsmail-5:S-INBOX:CreateNewLineFromSocket: 222[3016c80]: nsmail-5:S-INBOX:CreateNewLineFromSocket: sadsadasdadas 222[3016c80]: nsmail-5:S-INBOX:CreateNewLineFromSocket: 222[3016c80]: nsmail-5:S-INBOX:CreateNewLineFromSocket: --------------090108060605030301020609 222[3016c80]: nsmail-5:S-INBOX:CreateNewLineFromSocket: Content-Type: text/html; charset=us-ascii 222[3016c80]: nsmail-5:S-INBOX:CreateNewLineFromSocket: Content-Transfer-Encoding: 7bit 222[3016c80]: nsmail-5:S-INBOX:CreateNewLineFromSocket: 222[3016c80]: nsmail-5:S-INBOX:CreateNewLineFromSocket: <html><head></head> 222[3016c80]: nsmail-5:S-INBOX:CreateNewLineFromSocket: <body>sadsadasdadas</body> 222[3016c80]: nsmail-5:S-INBOX:CreateNewLineFromSocket: </html> 222[3016c80]: nsmail-5:S-INBOX:CreateNewLineFromSocket: 222[3016c80]: nsmail-5:S-INBOX:CreateNewLineFromSocket: --------------090108060605030301020609-- 222[3016c80]: nsmail-5:S-INBOX:CreateNewLineFromSocket: 222[3016c80]: nsmail-5:S-INBOX:CreateNewLineFromSocket: ) 222[3016c80]: nsmail-5:S-INBOX:STREAM:CLOSE: Normal Message End Download Stream 222[3016c80]: nsmail-5:S-INBOX:CreateNewLineFromSocket: 47 OK Completed -------------------------------------------------------------------------------- Above is I have tried on LAN connection in office I will try on dial-up connection tonight at home....but I am thinking this should be fixed now....will update this bug tomorrow...

cool, marking fixed.

Yes. Cool! Retesting on slow (dial-up) connection on today's windows 04-05-09-M15 commercial build: The results are exactly the same as I verified on LAN this afternoon. Marking as verified for the fix now!!