Closed
Bug 366839
Opened 18 years ago
Closed 18 years ago
images not displayed while creating replies/forwards (works in new mail)
Categories
(Thunderbird :: Message Compose Window, defect)
Thunderbird
Message Compose Window
Tracking
(Not tracked)
VERIFIED
FIXED
People
(Reporter: mkmelin, Assigned: mscott)
References
Details
(Keywords: regression, verified1.8.1.2)
Attachments
(1 file)
8.55 KB,
patch
|
Bienvenu
:
superreview+
|
Details | Diff | Splinter Review |
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•18 years ago
|
||
Seems v. similar to bug 343933.
Reporter | ||
Comment 2•18 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•18 years ago
|
||
are you trying to insert a remote image?
Reporter | ||
Comment 4•18 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•18 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•18 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>
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•18 years ago
|
||
I'm really starting to dislike the mail content policy manager.
Status: NEW → ASSIGNED
Flags: blocking-thunderbird2? → blocking-thunderbird2+
Assignee | ||
Comment 9•18 years ago
|
||
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•18 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•18 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•18 years ago
|
Comment 12•18 years ago
|
||
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.
Description
•