User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.8.1) Gecko/20061003 Firefox/2.0 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.8.1) Gecko/20061003 Firefox/2.0 mailto links including an image, whether local or on the www, are not loaded by Tbird. Attempts to send the message result in a perpertual attempt to attach the image and a message asking whether you have access to the file (the file is there - have tried it on various drives and directories). The mailto link is of the form: mailto:email@example.com?subject=Garbage&body=<html><head></head><body><h1>message</h1><img src='file:///c:/eg.gif' alt='eg'></body></html> Problem identical with Firefox and IE confirming this as almost certainly a Tbird issue, not a browser one. Reproducible: Always Steps to Reproduce: 1.set up a mailto link on a web page in format shown, refering to an actual image 2.click the link to open Tbird compose window 3.click send in the Tbird compose window Actual Results: image is not displayed in the compose window message cannot be sent Expected Results: image displayed in the message in which case it would send (copy and paste of same image to replace the image link works fine as observed elsewhere, the documentation about mailto: is very poor
It seems a pretty bad idea to be assuming the mail compose window will support <html> in the first place. Then, the file: URL is also risky -- in fact, it's likely to be deliberately not supported, as there's a potential security risk there (you might be able to spoof someone into clicking on a mailto link that uses file: to load, say, a password file or finance-program data file) -- see bug 135830. That said: If I enable HTML compose and use this new URL (with http: instead of file:), the resulting HTML in the compose window has clearly stripped the 'src' attribute from the URL: <h1>message</h1> <img alt="eg"> I'm not sure if that's by design or not.
Thanks for the comment. I understand very well the concern about security. However there are legitimate uses as well, as in this case. Not sure how that might be balanced - maybe a user setting in Tbird. Having said that, Tbird seems to think it should try to attach the image and not succeeding seems to be a bug. Re the comment about html, an application can generate a plain email with a mailto link. It seems reasonable to be able to generate an html format one instead so the result has some chance of printing in an acceptable format at its destination. (In this case the web page with the mailto link is on an intranet. The mailto links are generated by an application in response to incoming user requests and the email response gives the user the information he requested.)
(In reply to comment #2) > Having said that, Tbird seems to think it should try to attach the image and > not succeeding seems to be a bug. If I understand you correctly, I agree. This same problem occurs in Seamonkey, moving to Core. I'm presuming this is not Windows-specific. > (In this case the web page with the mailto link is on an intranet. The > mailto links are generated by an application in response to incoming user > requests and the email response gives the user the information he > requested.) I don't know what you're talking about here. If you have a very tightly controlled environment where you know the mailto will be feeding into a specific HTML-enabled mail client, there are probably three dozen better ways to get an image to the user than fooling around with a mailto URL.
Assignee: mscott → nobody
Status: UNCONFIRMED → NEW
Component: Message Compose Window → MailNews: Composition
Ever confirmed: true
OS: Windows XP → All
Product: Thunderbird → Core
QA Contact: message-compose → composition
Hardware: PC → All
Summary: image in mailto: link not loaded by Thunderbird → Loses 'src' attribute of <img> embedded in mailto:?body
Version: unspecified → Trunk
Product: Core → MailNews Core
Still repro. Thunderbird 52.0.1 (32-bit) Windows 7 64-bit
You need to log in before you can comment on or make changes to this bug.