531437 - inserted image not shown during composition if new mail started through external mailto: call

Status: VERIFIED FIXED

(Thunderbird :: Message Compose Window, defect)

Description

[Magnus Melin [:mkmelin]]

+++ 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:[e-mail]) 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.

Comment 1

[Mark Banner (:standard8)]

I'll take this, not sure what checks we're missing yet, but should be relatively simple to work out.

Comment 3

[Mark Banner (:standard8)]

I think we should fix this in 3.0.x if we can, but I don't think it blocks 3.0.1.

Comment 4

[Mike]

Has this bug been fixed yet? Do you know? It's making it harder to use SpyPig with Thunderbird...

Thanks,
Mike

Comment 5

[Mark Banner (:standard8)]

(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.

Comment 6

[Arivald]

(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").

Comment 7

[Arivald]

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.

Comment 8

[Nomis101]

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?

Comment 9

[raths]

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.

Comment 10

[Cesc]

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

Comment 11

[Mark Banner (:standard8)]

Attachment: The fix

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.

Comment 12

[David :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 13

[David :Bienvenu]

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...

Comment 14

[Mark Banner (:standard8)]

Hrm, that's because its missing a file...

Comment 15

[Mark Banner (:standard8)]

Attachment: The fix v2

This includes the test file intended to test this bug.

Comment 16

[David :Bienvenu]

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

Comment 17

[Mark Banner (:standard8)]

That's strange - it passed on try server.

Can you try uncommenting this line in test_checkInsertImage():

//  gComposeWin.sleep(500);

Comment 18

[David :Bienvenu]

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

Comment 19

[Mark Banner (:standard8)]

Checked in: http://hg.mozilla.org/comm-central/rev/97c3cf20f9ee

Comment 20

[Mark Banner (:standard8)]

AFAICT SeaMonkey doesn't have this issue, therefore only fixing on 3.1 as that's where the majority of our users are.

Comment 21

[Mark Banner (:standard8)]

Checked in to 1.9.2:

http://hg.mozilla.org/releases/comm-1.9.2/rev/8ccd4198deda

Comment 22

[Ludovic Hirlimann [:Usul]]

verifuied Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.11) Gecko/20101004 Thunderbird/3.1.5

Comment 25

[GaB]

I'm on Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) 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.