Steps to reproduce: -bring up messenger appruner.exe -mail; -bring up new mail composition window; -click on the Image icon on the toolbar; -choose an image file to insert; -OK dialog box; -send mail(HTML); -close manually the window; -get new mail and note: //note : the is no image file inserted expected: see image in the composition window (was working in M8) observed with 1999-07-20-12-M9/ windows build

This worksforme for build 1999071708, but since messenger wont let me view the headers of my mail I cannot really see anything to confirm this. But I know it works as I recieved the mail in 4.5 and it has the pic attached. Oh and when I click on attach a picture I go to a dir on my 'puter with pictures and none of them are shows until I put the view types to *.* . This is despite it showing picture files and the pics being jpegs. Is this a regression?

Yes, this is a regression. It was previously working (didn't try it in yesterday's build but definitely was OK in the last M8).

JF - pls assign a target milestone for this bug.

Sounds like this needs to be fixed for PR1, so I added a note to the Status Whiteboard

The insert image dialog dosn't work anymore, Pressing ok doesn't close the dialog, cancel works. move to M11

As the Ok button has been fixed by editor team (bug 12917), I was able to test insert image. It's works fine again

In the today's build (1999-09-16)i'm able to insert bmp image, sent message with it, but when i'm selecting it after receiving message body is empty and apprunner hangs.

What appends when you try to see the message with Comunicator 4.6? Does it work?

in 4.6 i'm able to see the inserted image. With 5.0 on IMAP i don't see the inserted image, the body is blank but it doesn't hang the way it does on the POP. It look like i need to modify the summary of the report : i can insert the image in a Compose Windows fine, it is a send/display problem now. So what would you prefer: modify the summary of this report with comments or resolve it as fixed and open another bug report?

You should do one more test: Create and send the message from 4.6 and open it with 5.0. If 5.0 still not able to display it correctly, then it's only a display problem, not a message composition one.

It looks like it is still a message composition problem.Here are the test results: - message with .bpm.jif file sent from 4.6 a) POP3: body is blank and apprunner freezes while loading; b) IMAP: body is blank but appruner doesn't freeze

You are telling me that if you send the message form 4.6, you can reproduce the display problem in 5.0. Right? Therefore it's a 5.0 display bug! not a 5.0 composition bug.

Did i say composition? Yes, Display problem certainly.

Ok, I close this bug again and Marina, please create a new one for the display issue. Thanks

Peter - pls work w/ Marina to create a new bug for the display problem if there isn't already one.

in today's windows build (1999-10-27-09M11) i'm running on the similar problem: when i'm inserting an image(i see it),when i get the message no image shows up. Same is true for attaching an image.If you have an alt.text it will only alt.text string that will show up in the message body

clearing resolution. Jeff, could this be related to bug 17057 [Dogfood] Data Loss: Sending jpeg/gif attachment becomes corrupted? This bug is currently assigned to RHP.

Yes, It should be a duplicate of bug 17057. Marina, please attach the image your are trying to send to this bug report. Thanks

Reassign to rhp and update the summary to reflect the real problem

changing qa assign to pmock@netscape.com

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

Changing explanation for a bit better description of message. - rhp

Putting on PDT+ radar

Yes, this is very bad, but I'm really not sure what happend to break this? Another mark for M12. - rhp

After doing some investigation, it turns out that we are somehow corrupting the RFC822 message during the SMTP operation. I will attach 2 messages to this bug, the first is what it looked like on my system in the temp directory and the second will be how it looked after being received by 4.7. - rhp

The MIME data is corrupted: before: BSQQX5VJIpgwB3IwV40wCptgPYqwl3NgB4yTW6CjWOSxNxFgABGgA1CwA+bzaPtjPhW0NiaA after: BSQQX5VJIpgwBNZADXcAMMiIjBQl4znB3V8BO/TEFeFALxxB49XTe+ sQg1mAMvNCExoAL8ZfhrsDhGJKCct0I This occurs in about 5 places, suggesting that there is some kind of end-buffer bug.

Jeff, could you look at this?

Are we reallying sending attachment using uuencode encoding? My build is not working well today. Do we allow user to use uuencode for attachments? Are we composing mhtml message or we simply attaching an image file which will cause the problem?

I tried to create an mhtml message but failed. I am not able to insert images to the editor.

Jeff, Can you attach gif/jpeg to a mail message? The problem also occurs when you send a mail attachment. Duplicate bug 17057

Thanks, Peter. I can reproduce the problem now.

Looks like we got biten by nsPipeOutputStream again. The request write amount is different than the actual write count which creates the corrupted image.

A fix in hand waiting for review.

Warren has fixed the problem. Reassign to him for marking it fixed.

I don't know anything about corruption here.

Warren, this is basically the nsPipe problem that write amount is less than the request amount problem which causes the message sent but corrupted. I am marking this as fixed. And I'll get a chance of free car washing for my suburban. Good deal. Thanks Warren. :-)

Verified on win, mac, and linux using the following builds: ftp://sweetlou/products/client/seamonkey/windows/32bit/x86/1999-11-18-09-M12/sea monkey32.exe ftp://sweetlou/products/client/seamonkey/macos/8.x/ppc/1999-11-18-08-M12/netscap e5-mac-M11.sea.bin ftp://sweetlou/products/client/seamonkey/unix/linux_glibc/2.2/x86/1999-11-18-08- M12/netscape-i686-pc-linux-gnu.tar.gz To verify this bug, I attached gif and jpeg images to a mail message from 5.0. The images were received in 5.0 and displayed correctly. I could not insert images in the mail editor or page composer. I logged bug 19440. Even though I could not insert an image, attaching files is an alternative method. Reference bug 17057