User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; pl; rv:22.214.171.124) Gecko/20090824 Firefox/3.5.3 (.NET CLR 3.5.30729) Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; pl; rv:126.96.36.199) Gecko/20091121 Thunderbird/3.0 During tests of my extension with Thunderbird 3 RC1 I found some serious problem. In many cases Composer does not load images, so compositing HTML mail become difficult, if possible. 1) If mail composition has been started from mailto: link then images does not show. 2) In reply or inline forwardng: a) images does not show if image has atributte moz-do-not-send="true" b) background page image does not show. 3) In new mail all images show properly. 4) Any kind of mail saved to Drafts are saved with images, except for images with moz-do-not-send="true". 5) When I double-click on missing image, i can view this image thumbnail in image editor. 6) In TC3 betas all works properly. 7) TB2 have same problem, but there i can change "network.protocol-handler.expose.file" pref, effectivelly fixing problem. As I check this problem is related to security code. Composer document has URL about:blank, while images loaded from files are URL's like file:///xxxxx. In <editor>, security code checks URL's and block images like in <browser>. Note, there is special exception in security code to allow new mails (mails with type equal to nsIMsgCompType.New) to show all images, without any security checks! Also security code does not care about saving mails with images (see point 4 above). So in effect user can't view images, but images are properly saved to Drafts. Also if user Try to send mail, all images are send properly. Only viewing of images is prohibited! I check bugzilla, and i found many bugs related to same problem, for example #527649, #386293, #466133, #472035, #502165, #385197 and more. In bug #386293 Mark Banner said: > I suspect this may be a slight regression caused by bug #527664. Reproducible: Always Steps to Reproduce: 1. Run TB from mailto: link 2. Insert any image into body Actual Results: Image does not show, is blocked. Expected Results: Image should be visible!
The mailto problem seems to be a dup of bug 531437 but maybe we should keep this open as a tracking bug for image problems in html compositions. I can reproduce the "mailto" problem when opening an editor window when the mailto is in a browser window only. There are other issues with images, just recently I ran into an "over-escaping" of the image url when pasting in an image copied from a browser window. %7c instead of | character.(which happens also when applying inline styles to an image)
(In reply to comment #1) > The mailto problem seems to be a dup of bug 531437 but maybe we should keep > this open as a tracking bug for image problems in html compositions. > I can reproduce the "mailto" problem when opening an editor window when the > mailto is in a browser window only. I don't think we nee another tracking bug. This bug is really just related to recent content policy changes as to when we do/don't display images. > There are other issues with images, just recently I ran into an "over-escaping" > of the image url when pasting in an image copied from a browser window. > %7c instead of | character.(which happens also when applying inline styles to > an image) Yes, but lets keep those separate to content policy issues please.
Arivald, Marking as dupe of bug 531437 The other issues that I'm aware of are bug 307023 and bug 224733 If you have more, please file a separate bug.