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.)
Seems v. similar to bug 343933.
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...
are you trying to insert a remote image?
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:126.96.36.199pre) Gecko/20070131 Thunderbird/2.0pre ID:2007013104
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 :).
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)
I'm really starting to dislike the mail content policy manager.
Status: NEW → ASSIGNED
Flags: blocking-thunderbird2? → blocking-thunderbird2+
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.
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 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+
Status: ASSIGNED → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → FIXED
verified with 188.8.131.52 rc2 build on WinXP
Status: RESOLVED → VERIFIED
Keywords: fixed184.108.40.206 → verified220.127.116.11
You need to log in before you can comment on or make changes to this bug.