images not displayed while creating replies/forwards (works in new mail)

VERIFIED FIXED

Status

Thunderbird
Message Compose Window
--
major
VERIFIED FIXED
11 years ago
11 years ago

People

(Reporter: Magnus Melin, Assigned: Scott MacGregor)

Tracking

({regression, verified1.8.1.2})

Trunk
regression, verified1.8.1.2
Bug Flags:
blocking-thunderbird2 +

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

11 years ago
When creating a new mail, inserting (or copy-pasting) images into the mail body works fine. 

When doing a *reply* or forward inserting an image does not make it show up (you only get the red little square). The images seem to show fine to the recipient. 

Seen on branch and trunk. (OS=All according to mz forums.)

Comment 1

11 years ago
Seems v. similar to bug 343933.
(Reporter)

Comment 2

11 years ago
Similar, but i don't think it's a dupe. (Wrong timeframe.)

This broke on branch (linux builds) 20061120 -> 20061121.
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=MOZILLA_1_8_BRANCH&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2006-11-20+03%3A00%3A00&maxdate=2006-11-21+03%3A00%3A00&cvsroot=%2Fcvsroot

Bug 357321 really stands out as the likely cause... 
Blocks: 357321
Flags: blocking-thunderbird2?
(Assignee)

Comment 3

11 years ago
are you trying to insert a remote image? 
(Reporter)

Comment 4

11 years ago
Nope, just a normal local image (on windows copy paste also shows this). Though remote images show the same problem - shown with new mail, but not in replies.

Still present using:
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.2pre) Gecko/20070131 Thunderbird/2.0pre ID:2007013104
(Assignee)

Comment 5

11 years ago
Blocking remote images in this case is expected after the security bugs we fixed in the content policy. even though it's not ideal.

But you should be able to load a file url, but sure enough the file url for the image is running afoul of the content policy manager which analyzes all http, https and file url loads in a compose window. I can't remember why we block file urls by default, I need to re-remember :).

Comment 6

11 years ago
I thought the general reason to block file: URLs was to avoid someone replying to a message containing, e.g.
   <a href="file:///c|windows.ini" style="display:none" moz-do-not-send=false>

Comment 7

11 years ago
After deeper search on the original bug, I'm a little bit confused :
On my laptop at work (running winXP+latest TB 2 build), I have no problem.
Whearas on my laptop at home, for some messages it works, for other it doesn't !
Apparently for messages that really looks like HTML messages (with images already in them, for instance), the issue does not occur.
But for messages that look like plain text (although looking at the message source shows that the message has been sent in both text AND html), then the issue occurs.
Bye the way, I'm talking here about copying/pasting an inline image (not a remote one)
(Assignee)

Comment 8

11 years ago
I'm really starting to dislike the mail content policy manager.
Status: NEW → ASSIGNED
Flags: blocking-thunderbird2? → blocking-thunderbird2+
(Assignee)

Comment 9

11 years ago
Created attachment 254200 [details] [diff] [review]
a fix

We want to continue to block remote content that's inside quoted text. But we want to allow the user to paste or insert remote images into replied and forwarded message compositions.

Fortunately, after inserting quoted content into the document, mail compose walks the dom of quoted material, tagging all dom elements with remote urls with a moz-do-not-send attribute. 

The content policy now leverages this behavior. But it only works when we have already inserted the quoted text into the document. So we first need to keep track of the compose window state for inserting quoted content, continuing to deny remote content during the quoting process.

Now for image elements only, even if the content policy decides to reject the load, override that decision if the image element doesn't have the moz-do-not-send attribute applied to it and we aren't inserting quoted content.
(Assignee)

Comment 10

11 years ago
Comment on attachment 254200 [details] [diff] [review]
a fix

David, see comment 9 for an overview of this approach.
Attachment #254200 - Flags: superreview?(bienvenu)

Comment 11

11 years ago
Comment on attachment 254200 [details] [diff] [review]
a fix

looks good

One edge case - does this handle after the fact quoting, i.e., by picking options | quote message in the compose window?
Attachment #254200 - Flags: superreview?(bienvenu) → superreview+
(Assignee)

Updated

11 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 11 years ago
Keywords: fixed1.8.1.2
Resolution: --- → FIXED
verified with 2.0.0.0 rc2 build on WinXP
Status: RESOLVED → VERIFIED
Keywords: fixed1.8.1.2 → verified1.8.1.2
You need to log in before you can comment on or make changes to this bug.