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

Status: RESOLVED WORKSFORME

(Thunderbird :: Message Compose Window, defect)

Description

[Magnus Melin [:mkmelin]]

STR:
1) Start a new mail (e.g. to [e-mail] or yourself) 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. 

The message is received ok. The issue can be seen both on 2.0 and trunk.

Similar to bug 359852, but that's working now, except for this case.

Comment 2

[Magnus Melin [:mkmelin]]

Windows also based on the dupe.

Comment 3

[Arivald]

If you add property "network.protocol-handler.expose.file", and set its value to "true", then all will work OK.
It will also fix another problem i have, with displaying background image while replying or forwarding.

But i'am not sure how much security risk it is.
As far as i check, all works ok.

Comment 6

[Magnus Melin [:mkmelin]]

This is WFM on current trunk.

Comment 8

[Arivald]

I have this problem again, in TB 3 RC. My images are loaded via HTML template
by my extension. 
Anyway, even if I try to insert image manually it does not
work.

To make it work in TB 2 i used (comment #3) 
pref("network.protocol-handler.expose.file", true);

But it no longer works in TB 3 RC.

I suspect it is again conflict with security code. Someone somewhere adjust
secutirty code, and now loading image contents in mailto: mail is considered as
insecure.

Indeed, mailto: with body coming from link (from external source) may be
vunerable to attacks. But body parts from signature or images loaded manually
by user should be always considered as safe.

I think this check should not be applied to all images in mailto: mail. 
Part of code which imports mail body from clicked link should just mark any
external content links (like images) as unsafe, and security code should
disable only this unsafe content, not all content.

I think this bug should be reopened.

Comment 9

[Mark Banner (:standard8)]

(In reply to comment #8)
> I think this bug should be reopened.

Given that it was working and now it isn't, it is quite clearly not this same bug as this goes back to TB 2. Therefore please file a new bug with clear STR so that we can track it as a new bug. I suspect this may be a slight regression caused by bug 527664.

Comment 10

[Magnus Melin [:mkmelin]]

I filed bug 531437 about it.