User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.9) Gecko/20050711 Firefox/1.0.5 (stipe s8v4) Build Identifier: version 1.0+ (20050821) Images are being blocked with addition of moz-do-not-send="true" in the image src tag Reproducible: Always Steps to Reproduce: 1.create an html composed message with an inline image (use insert | image and browse to any image file) 2.kill the composition process and select 'save as draft' 3.re-open the saved draft and observe that the image is viewable in compose, but the image tag has been altered to <img moz-do-not-send="true" (This can be confirmed by using Edit | select all | insert html to view the html 4.complete the composition and send the file to yourself, or view the 'sent file The image will not be sent Actual Results: Images are blocked with <img moz-do-not-send="true" added to the image tag. Expected Results: Message content with regard to images should be maintained. The same <img moz-do-not-send="true" is added if the message is saved by the File |send later function. Subsequent 'edit message as new' attempts result in lost images.

I believe the regression range on this is on or about 08/19/05

I'm sure this was caused by our fix for Bug 303752

I don't have a current build (see bug 305507) so I can't check the regression. What I see with the 0806 trunk build is: the draft is saved with <img src="cid:part1.nnnnn.nnn@well.com" ...> When the draft is reopened, the source within the editor is [wrapping mine] <img src="mailbox:///<path>/mail.well.com/Drafts?number=xxxxxx&amp; part=1.2&amp;filename="..." ...> But when the message is sent, the image is included and the URL reverts to: <img src="cid:part1.nnnnn.nnn@well.com" ...> and the message displays correctly. Xref bug 270380. Also, probably unrelated, but see bug 224733. (In reply to comment #2) > I'm sure this was caused by our fix for Bug 303752 Scott, since that bug is "Access Denied" could you give a synopsis?

that bug does the following: when forwarding a message, don't allow the contents of the forwarded message to refer to any images or files from your hard disk. i.e. nothing local.

I wasn't able to reproduce Joe's scenario. The images always showed up. But I did see the image getting marked for do not send incorrectly when sending a draft which we shouldn't be doing. This change just makes our tag embedded parts method only fire when forwarding inline so we don't do it when you are opening a draft. Note: reply happens through a separate code path and still calls tag embedded objects.

(In reply to comment #4) > that bug does the following: when forwarding a message, don't allow the contents > of the forwarded message to refer to any images or files from your hard disk. > i.e. nothing local. Not knowing what security threats were addressed in the bug, and considering I am talking about html messages here, consider the following: Your original checkin had the following description: Bug #303752 --> treat forward inline like we do for replying when deciding which attachment parts to attach. Well that is not what happens with your original patch. Reply in html, quotes and cites the inline images and preserves them in the reply. After the patch, they are still quoted and sent in the reply. And, isn't forward inline meant to forward all the message content? BTW forward as attachment still sends the inline images.(with this patch installed) If we are talking about image links such as <img alt="" src="file:///C:/gifprops/2.gif" height="32" width="32"> which I would consider local data, I have never seen the result to be that local data is included in the message. The link to my local data is just sent in the message, which can do no harm at all.(and no good) An additional regression is that if you use a template with an inline image, that image is also blocked, rendering the template useless for images. Edit as new, with a saved message also blocks the image. I'll test further when your 2nd patch is checked in.

I checked this patch in to see if it makes things better for Joe. Joe, can you try an 8/26 trunk build when they come out tomorrow and see if it is better?

today's compose window on the trunk was hosed so I doubt you can test the new behavior. Try again tomorrow (8/27) and let us know. You should be able to edit a draft without the attachment problem.

with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20050827 Thunderbird/1.6a1 ID:2005082708 All the above symtoms are gone, and forward inline still blocks images as desired. I'll run with this for the rest of the weekend, to see if anything else shows.

I've used all my usual save/template/send later stuff seems fine. Marking fixed. Branch?

re-opening. please don't mark bugs as fixed for me :) I'll mark it fixed when i'm ready and it's in the branch :)

now it's fixed on the branch. Thanks a lot for helping us track this down and test it Joe. I appreciate that.

It appears this fix has regressed, branch and trunk: bug 315625.

Comment on attachment 193755 [details] [diff] [review] limit our embedded object tagging to just forward as inline a=dveditz for drivers for the aviary101/moz17 branches.

I landed this patch on the branches.

verified on the 1.7 branch using Mozilla 1.7.13 Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.13) Gecko/20060302. I followed the steps in the initial report and everything works as expected.

Verified with Thunderbird windows build - version 1.0.8 (20060317)