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

VERIFIED FIXED in Thunderbird 3.3a1

Status

Thunderbird
Message Compose Window
VERIFIED FIXED
8 years ago
6 years ago

People

(Reporter: Magnus Melin, Assigned: standard8)

Tracking

({regression})

unspecified
Thunderbird 3.3a1
regression
Dependency tree / graph
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(blocking-thunderbird3.1 .5+, thunderbird3.1 .5-fixed)

Details

(URL)

Attachments

(1 attachment, 1 obsolete attachment)

(Reporter)

Description

8 years ago
+++ 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:nobody@mozilla.org) 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.
(Assignee)

Comment 1

8 years ago
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: --- → ?
(Assignee)

Updated

8 years ago
Blocks: 531419

Updated

8 years ago
Duplicate of this bug: 531419
(Assignee)

Comment 3

8 years ago
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
(Assignee)

Updated

8 years ago
Blocks: 527649

Comment 4

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

Thanks,
Mike
(Assignee)

Comment 5

7 years ago
(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

7 years ago
(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

7 years ago
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

7 years ago
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

7 years ago
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

7 years ago
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
(Assignee)

Comment 11

7 years ago
Created attachment 479040 [details] [diff] [review]
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.
Attachment #479040 - Flags: review?(bienvenu)
(Assignee)

Updated

7 years ago
blocking-thunderbird3.1: --- → .5+
(Assignee)

Updated

7 years ago
Attachment #479040 - Flags: review?(dmose)
(Assignee)

Updated

7 years ago
Attachment #479040 - Flags: review?(dmose)

Comment 12

7 years ago
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

7 years ago
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-
(Assignee)

Comment 14

7 years ago
Hrm, that's because its missing a file...
(Assignee)

Comment 15

7 years ago
Created attachment 479437 [details] [diff] [review]
The fix v2

This includes the test file intended to test this bug.
Attachment #479040 - Attachment is obsolete: true
Attachment #479437 - Flags: review?(bienvenu)

Comment 16

7 years ago
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
(Assignee)

Comment 17

7 years ago
That's strange - it passed on try server.

Can you try uncommenting this line in test_checkInsertImage():

//  gComposeWin.sleep(500);

Comment 18

7 years ago
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+
(Assignee)

Comment 19

7 years ago
Checked in: http://hg.mozilla.org/comm-central/rev/97c3cf20f9ee
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Target Milestone: --- → Thunderbird 3.3a1
(Assignee)

Comment 20

7 years ago
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 → ---
(Assignee)

Updated

7 years ago
Attachment #479437 - Flags: approval-thunderbird3.1.5+
(Assignee)

Comment 21

7 years ago
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:1.9.2.11) Gecko/20101004 Thunderbird/3.1.5
Status: RESOLVED → VERIFIED
Keywords: verified-thunderbird3.1

Updated

7 years ago
Duplicate of this bug: 527649

Updated

7 years ago
Duplicate of this bug: 554182

Comment 25

6 years ago
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.
You need to log in before you can comment on or make changes to this bug.