Closed Bug 31191 Opened 25 years ago Closed 24 years ago

Need to have interrupting/stop for Layout

Categories

(SeaMonkey :: MailNews: Message Display, defect, P3)

Product:
SeaMonkey
Component:
MailNews: Message Display
Platform:
x86
Windows 98
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: huang, Assigned: Bienvenu)

Details

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.
QA Contact: lchiang → huang
David?
Assignee: phil → bienvenu
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.
Status: NEW → ASSIGNED
Target Milestone: M15
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
Target Milestone: M15 → 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.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → 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!!
Status: RESOLVED → VERIFIED
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.