Inline images are being blocked on Forward or composition from drafts

RESOLVED FIXED

Status

MailNews Core
Composition
--
major
RESOLVED FIXED
13 years ago
10 years ago

People

(Reporter: JoeS1, Assigned: Scott MacGregor)

Tracking

({fixed1.8, regression, verified1.7.13})

Trunk
x86
Windows XP
fixed1.8, regression, verified1.7.13
Dependency tree / graph
Bug Flags:
blocking1.7.13 +
blocking-aviary1.0.8 +

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: regression from bug 303752)

Attachments

(1 attachment)

(Reporter)

Description

13 years ago
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.
(Reporter)

Comment 1

13 years ago
I believe the regression range on this is on or about 08/19/05
(Assignee)

Comment 2

13 years ago
I'm sure this was caused by our fix for Bug 303752
Blocks: 303752

Comment 3

13 years ago
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?
(Assignee)

Comment 4

13 years ago
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. 
(Assignee)

Comment 5

13 years ago
Created attachment 193755 [details] [diff] [review]
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.
Attachment #193755 - Flags: superreview?(bienvenu)

Updated

13 years ago
Attachment #193755 - Flags: superreview?(bienvenu) → superreview+
(Reporter)

Comment 6

13 years ago
(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.

(Assignee)

Comment 7

13 years ago
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?
(Assignee)

Comment 8

13 years ago
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. 
(Reporter)

Comment 9

13 years ago
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.
(Reporter)

Comment 10

13 years ago
I've used all my usual save/template/send later stuff seems fine.
Marking fixed. Branch?
Status: UNCONFIRMED → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → FIXED
(Assignee)

Comment 11

13 years ago
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 :)
Status: RESOLVED → UNCONFIRMED
Resolution: FIXED → ---
(Assignee)

Updated

13 years ago
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Keywords: regression
Target Milestone: --- → Thunderbird1.1
(Assignee)

Comment 12

13 years ago
now it's fixed on the branch.

Thanks a lot for helping us track this down and test it Joe. I appreciate that.
Status: ASSIGNED → RESOLVED
Last Resolved: 13 years ago13 years ago
Keywords: fixed1.8
Resolution: --- → FIXED
Component: Message Compose Window → MailNews: Composition
Product: Thunderbird → Core
Target Milestone: Thunderbird1.1 → ---
Flags: blocking1.7.13+
Flags: blocking-aviary1.0.8+
Whiteboard: regression from bug 303752

Comment 13

12 years ago
It appears this fix has regressed, branch and trunk: bug 315625.
(Assignee)

Updated

12 years ago
Blocks: 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.
Attachment #193755 - Flags: approval1.7.13+
Attachment #193755 - Flags: approval-aviary1.0.8+

Comment 15

12 years ago
I landed this patch on the branches.
Keywords: fixed-aviary1.0.8, fixed1.7.13
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.
Keywords: fixed1.7.13 → verified1.7.13
Verified with Thunderbird windows build - version 1.0.8 (20060317)
Keywords: fixed-aviary1.0.8 → verified-aviary1.0.8
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.