Build Date & Platform Bug Found: Win32 commercial seamonkey build 1999-12-17-13-m12 installed on P166 Win98 Linux commercial seamonkey build 1999-12-17-10-m12 installed on P200 RedHat 6.1 MacOS commercial seamonkey build 1999-12-17-10-m12 installed on G3/400 OS 8.6 Overview Description: I just verified bug 18866 using a Mac 12/7 build, but found that this message fails on the 12/17 Mac M12 build. I re-tested on Windows and Linux and seamonkey crash. Nothing is displayed in the message pane, but I crash when I try to load a different folder/message. It crashes under IMAP and POP. I will attach my sample test message to this bug. Steps to Reproduce: 0) Download the sample mail file 1) Copy the sample mail file in the local mail location in 4.7 and 5.0 2) launch your IMAP 4.7 profile and open Messenger 3) Open the Local Mail and view the mail message The message should load successfully. 4) Copy the mail message to to your IMAP server. 5) Log into you mail 6) Select the test message It loads fine. -- 7) Launch 5.0 8) Open Messenger 9) Select your INBOX and log in. 10) Select your mail message It fails to load. 11) Select another folder/message Crash. Actual Results: The message fails to load. The status bar says Document done but nothing appears in the message pane. I try to select anther message/folder then I crash. Expected Results: It should load the mail message. Additional Builds and Platforms Tested On: Communicator 4.7 RTM on win32, macOS, and Linux loads the sample message just fine. Additional Information: Rather than re-open bug 16786 and 18866, I wanted to log a new because, they were fixed at separate dates. It sounds to me like a different problem.

Changing qa assigned to pmock@netscape.com

Reference talkback incidence 2780690 and 2780692

Unable to write to the output stream problem :-( - rhp

beta stopper

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

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

Scott/Judson, I think I need some help on this one. Its a stream/buffering issue. We get to the point where we are trying to write to an output stream and it fills up. I've tried NOT failing and continuing to write, but we are getting error return codes that causes us to quit. Maybe its a case where we write ZERO bytes and get an error code that shouldn't be treated as an abort failure? I am going to see what the error code is when we fail. Maybe we have to be more intelligent than NS_FAILED()? Ideas? - rhp

Ok, this bug will actually be fixed when mscott lands his changes for the performance Bug #22960. Then, I will change the XUL emitter to be able to handle large files like this. Reassigning to mscott for his checkins and then he will reassign back to me. - rhp

I just verified with the new message display stuff that I can view the test message Peter posted to this bug just fine. Rich, do you want me to just mark this as fixed so QA can go verify it?, or do you want to keep this as a reminder for changing the xul emitter in case we are displaying the message in the browser window?

Marking this as fixed. Rich, do you want a new bug to track fixing the xul emitter in case you use it for displaying messages in the browser?

Verified as fixed on win32, linux, and macos using the following builds: ftp://sweetlou/products/client/seamonkey/windows/32bit/x86/2000-01-12-11-M13/sea monkey32e.exe ftp://sweetlou/products/client/seamonkey/unix/linux_glibc/2.2/x86/2000-01-11-10- M13/netscape-i686-pc-linux-gnu.tar.gz ftp://sweetlou/products/client/seamonkey/macos/8.x/ppc/2000-01-12-08-M13/netscap e5-mac-M13.sea.bin I no longer reproduce the crash.