305557 - Inline images are being blocked on Forward or composition from drafts

Status: RESOLVED FIXED

(MailNews Core :: Composition, defect)

Description

[Joe Sabash [:JoeS1]]

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.

Comment 1

[Joe Sabash [:JoeS1]]

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

Comment 2

[Scott MacGregor]

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

Comment 3

[Mike Cowperthwaite]

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:[e-mail]"  ...>
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:[e-mail]"  ...>
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?

Comment 4

[Scott MacGregor]

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. 

Comment 5

[Scott MacGregor]

Attachment: limit our embedded object tagging to just forward as inline

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.

Comment 6

[Joe Sabash [:JoeS1]]

(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.

Comment 7

[Scott MacGregor]

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?

Comment 8

[Scott MacGregor]

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. 

Comment 9

[Joe Sabash [:JoeS1]]

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.

Comment 10

[Joe Sabash [:JoeS1]]

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

Comment 11

[Scott MacGregor]

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 :)

Comment 12

[Scott MacGregor]

now it's fixed on the branch.

Thanks a lot for helping us track this down and test it Joe. I appreciate that.

Comment 13

[Mike Cowperthwaite]

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

Comment 14

[Daniel Veditz [:dveditz]]

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.

Comment 15

[David :Bienvenu]

I landed this patch on the branches.

Comment 16

[Marcia Knous [:marcia]]

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.

Comment 17

[Tracy Walker [:tracy]]

Verified with Thunderbird windows build - version 1.0.8 (20060317)