+++ This bug was initially created as a clone of Bug #386293 +++ So this was broken in tb2, got fixed and regressed again with checkin of bug 527664 (as per Bug #386293 commment 9) STR: 1) Start a new mail (e.g. to mailto:email@example.com) by clicking a link in the browser 2) Insert > Image 3) Observe: image is not shown, just the red place holder If I start the mail by clicking the mailto inside thunderbird, all is well. Also if I manually fill in the address. It's only a problem when clicking a mailto URL in the browser.
I'll take this, not sure what checks we're missing yet, but should be relatively simple to work out.
Assignee: nobody → bugzilla
blocking-thunderbird3.0: --- → ?
I think we should fix this in 3.0.x if we can, but I don't think it blocks 3.0.1.
blocking-thunderbird3.0: ? → needed
Has this bug been fixed yet? Do you know? It's making it harder to use SpyPig with Thunderbird... Thanks, Mike
(In reply to comment #4) > Has this bug been fixed yet? Do you know? It's making it harder to use SpyPig > with Thunderbird... The bug is marked as "New". It is not marked as "Fixed", therefore, unless a different bug has fixed this, then it has not been fixed. I may have time to investigate it in a week or so, hopefully before 3.0.5 builds start.
(In reply to comment #1) > I'll take this, not sure what checks we're missing yet, but should be > relatively simple to work out. This is not a simple bug in code. It is bug in design. Some time ago somebody start protecting users from sites like SpyPig.com (mail tracker). For example, if user recive email with tracking image, then while he reads this mail, our standard TB content policy will block this image downloading (in default settings, of course). But if this user try to reply suchj mail, then Composer will try to download this image.Blocking such download will protect user privacy. But current solution is very wrong: it blocks all images in replies/forwards. I think it should block only images within replied content. For example, code which prepare citation <blockquote> should scan quoted text and mark every blocked image using some special attribute, like "moz-do-not-send" for links. And security code in Composer should take this attribute into account, and block only remote images in cited content. All images added by user manually should be visible, either if it is untrusted. User add it, so assume user know what he doing, right? Of course, if users settings allow some remote images (he trust domain), such images should also be visible in cited reply. Only untrusted images should be blocked. Note: Maybe security can't access to <img> tags... In this case, citing code may change URL of blocked image to URL of some internal replacement (ex: "chrome://messenger/skin/blocked.png", with red box and text "blocked").
I forgot about "mailto:", I write only about replies/forwards. But of course this is same problem, and solution should be similar. Simply, code which process "mailto:" URL should mark some image URLs (not only for <img>, but for CSS too) as insecure. It should explicit check while processing "mailto:" URL, not just blocking all as in current code.
I know one user report, that this issue also affects signatures. If you use an image as your signature and open the compose window through an external mailto call, than you only see a placeholder instead of your signature. I've tested this and can confirm it for 3.0, 3.1 and 3.2! This is really bad, isn't it?
Hello, I don't know if my problem is similar but there it is : When I click on a link to an e-mail from a website, the logo does not appear in the signature. When I save this email as a draft, I found my logo.
I think it must be related to Bug 527649 I have this same problem on windows 7 and windows XP SP3 and Thunderbird 3.0.4
This changes the content policy so that composing messages created from mailto links are treated in the same way as new mail - remote content is allowed. I think this makes sense - we're composing a new email, and we can't validate against any previous senders because there aren't any. Also included is a mozmill test which inserts an image and checks it gets loaded (there are already other tests for not loading images in reply/forward windows). I'm currently running this through the try server, but mainly just to check for any possible random results on the mozmill test.
Attachment #479040 - Flags: review?(bienvenu)
Comment on attachment 479040 [details] [diff] [review] The fix I don't see the mozmill test fail on Windows when I remove the nsMsgContentPolicy.cpp part of the patch. The code change itself looks fine.
Comment on attachment 479040 [details] [diff] [review] The fix minusing based on test issue - apologies if I've misunderstood how to run the test. I ran the content-policy directory tests...
Attachment #479040 - Flags: review?(bienvenu) → review-
Hrm, that's because its missing a file...
This includes the test file intended to test this bug.
now the test fails, but unfortunately, that's with the whole patch applied :-( TEST-PASS | setupModule TEST-PASS | test_openComposeFromMailToLink TEST-UNEXPECTED-FAIL | c:\builds\tbirdhq\mail\test\mozmill\content-policy\test-c ompose-mailto.js | test_checkInsertImage EXCEPTION: Loading of image has been unexpectedly blocked in a mailto compose window at: test-compose-mailto.js line 139 test_checkInsertImage() test-compose-mailto.js 139 frame.js 474 frame.js 530 frame.js 573 frame.js 426 frame.js 585 server.js 164 server.js 168 TEST-PASS | test_closeComposeWindowAndTab
That's strange - it passed on try server. Can you try uncommenting this line in test_checkInsertImage(): // gComposeWin.sleep(500);
Comment on attachment 479437 [details] [diff] [review] The fix v2 I think I must have had build issues - the test is passing now. Second line is over-indented. + // Open a content tab with the mailto link in it. + // To open a tab we're going to have to cheat and use tabmail so we can load + // in the data of what we want. and copyright is 2001, probably should be 2010
Attachment #479437 - Flags: review?(bienvenu) → review+
Status: NEW → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → FIXED
Target Milestone: --- → Thunderbird 3.3a1
AFAICT SeaMonkey doesn't have this issue, therefore only fixing on 3.1 as that's where the majority of our users are.
blocking-thunderbird3.0: needed → ---
Attachment #479437 - Flags: approval-thunderbird3.1.5+
Checked in to 1.9.2: http://hg.mozilla.org/releases/comm-1.9.2/rev/8ccd4198deda
status-thunderbird3.1: --- → .5-fixed
verifuied Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:126.96.36.199) Gecko/20101004 Thunderbird/3.1.5
Status: RESOLVED → VERIFIED
I'm on Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:188.8.131.52) Gecko/20110303 Thunderbird/3.1.9 I don't know if it is the same issue, but it looks like. I have several accounts, one of them with signature with an image in it. If I reply an email received in another account and then switch to the one with the signature, TB puts my signature but with the broken image icon. If I edit the link of the image by hand, even when the shown one is correct, then apply, it shows the image correctly.
You need to log in before you can comment on or make changes to this bug.