Closed Bug 1366349 Opened 7 years ago Closed 7 years ago

Ability to permanently unblock individual image files

Categories

(Thunderbird :: Untriaged, defect)

Product:
Thunderbird
Component:
Untriaged
Version:
52 Branch
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
VERIFIED WONTFIX

People

(Reporter: chris, Unassigned)

Details

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:53.0) Gecko/20100101 Firefox/53.0
Build ID: 20170504105526

Steps to reproduce:

Including image files from local hard drives in messages is now blocked as of version 52. This breaks things like signature templates that include images. 


Actual results:

You can unblock the file every time you send a message, but that is not a good solution when you are sending out a large number of emails each day. 

The other option is to convert it to bas64 and embed it in your signature template -- confusing for many people.


Expected results:

Add an option to the "Thunderbird has blocked a file from loading in this message..." to permanently unblock an image file and allow it in future messages.

Prevents accidentally leaking files from the local hard drive while not breaking all the templates out there that include an img tag.
(In reply to Chris Daley from comment #0)
> This breaks things like signature templates that include images. 
What's a "signature template"? Do you have old templates? You need open, unblock the file and save them again.

The signatures that TB let's you configure still work, see bug 1364718 comment #3. That was implemented in bug 1316570.

The add-on "Signature Switch" works. So what exactly doesn't work? In bug 1364718 someone complained approximately the same thing, but never gave any details, so I closed the bug.
Sorry,

Many of us use QuickText to insert chunks of HTML, including signature lines, into outgoing e-mail messages. The HTML includes IMG tags pointing to files on my hard drive. 

There are a number of other Add Ons that also insert IMG tags into email messages and are "broken" at the moment according to forums.mozillazine.org.

So, rather than having to replace all current IMG tags with something like...

  img src="data:image/png;base64,iVBORw0KGgodJ9kSgwgf491nQcUPdkkzb8TXsQ8iH5dLqfXcgRHdFAgAddGm47jDP8XaMuHHYcUkuWqyIJe.........

... I'm requesting that we can continue to use ...

  img src="file:///C:/some_folder/logo_sig.png" 

... and do a one-time permanent unblock of the file.
I knew this would be add-on related. The add-on authors should fix their add-ons and convert file: URLs to data: URLs.

I don't think we will implement what you request.
Status: UNCONFIRMED → RESOLVED
Closed: 7 years ago
Resolution: --- → WONTFIX
QuickText just inserts text or HTML. Is not designed to parse HTML and do image conversion. There is no easy fix on their end other than to completely rewrite the Add On.

For those who need it, you can use something like http://picbase64.com/ to convert images to Base64. 

The resulting HTML for my HTML signature expands from 322 bytes to 3.6 KB. Hope you reconsider.
The 3.6 KB will be sent anyway. It's now technically *impossible* to view file-based images in compositions, so there's nothing to reconsider, sorry. The only thing we could implement would be an auto-unblock, so every time we see the file, we unblock it.

Magnus?
Flags: needinfo?(mkmelin+mozilla)
I don't think we should add any list of files to auto-unblock. But we should fix Quicktext - and yes it should be completely possible and not even too hard to fix it in that end. 

Hmm, what ever happened with the code, did it ever end up on github? Google doesn't help me...
Flags: needinfo?(mkmelin+mozilla) → needinfo?(rkent)
I save a lot of graphics as drafts and have them scheduled. If I go to edit one, the graphics are often gone (not always!) and I have to approve them one at a time to get them to load back into the message. I have on rare occasions (as in 10 minutes ago) tried to click the links to allow the messages and only got placeholder boxes

It is a bug and it is annoying. There should be a way to shut off this behavior if you are not in an environment that needs it (whatever that may be)

I have Quicktext installed but am not using it to add graphics. Mine were all dragged in and appeared inline
Thanks!
Sorry, I really don't understand the workflow that isn't working for you. Once you insert a file-based image, it's converted to a data: URL and stored in the draft. It should not get lost after that.
Agreed it should not. But it does on occasion.
I save a draft with inline pictures
I need to edit it so I open it back up and the pictures now require me to click a link for each and every image in the email presumably to authorize it

I just had to edit 3 and they were all the same. I lost the graphics in one of them

Thanks for commenting
I still don't understand. For an image to appear in a composition, it is one of two cases:

1) Data: URL if you dragged in a picture, inserted one from a file, or pasted
   a HTML fragment referencing a file-based image.
2) A reference to an image on the web.

In neither case, the picture should get lost.

"the pictures now require me to click a link for each and every image".
Well, where does that "link" appear and what does is say? There are in fact no links. There are blocked content and remote content notifications. As an aside: TB has sooooo many functions that it is hard to understand a report if you don't call things by their correct name. If in doubt, attach a screenshot above ("Attach File").
THe link appears to be an internal Thunderbird link and must be clicked to ok the picture
No references to web graphics. I drag them from a folder on my hard drive to the body of an open email and they appear correctly
I save them as drafts
If I edit one THEN the issue pops up; it won't load the graphics without the block message and the need to click the links one at a time
Sorry, I still don't understand your report. What is an "internal link"? Please attach a screen shot.

If you drag an image onto the body of an open e-mail composition, this image will be included in the composition and converted to a data: URL. Double-click the image and you will see something like:
  data:image/jpeg;filename=xxx.jpg;base64,/9j/4…oz

When you save the composition as draft and edit the draft again, all is well again. Why don't you save such a draft as .eml file (drag onto the desktop) and attach it here ("Attach File" above").

If the described workflow doesn't work, then you might have an incompatible add-on that's interfering.

I repeat:
- drag image onto open compose window just works
- save as draft and edit draft later: just works, no "internal links" to be clicked.
@jorge K
I don't know what more I can tell you. The are links to graphics apparently in my mail folder. I must click on them one by one to make the graphics appear
It happens randomly
I failed to mention that I schedule these with the SEND LATER add on but I would not be quick to jump on that as the problem as that basically changes the header and saves as a draft. Mine appears to be a security issue with graphics
Thanks
I tried very hard to help you. I asked for screenshots showing the problem and a sample message where images are not displayed. You didn't provide anything.

BMO is really not a support forum, however, I try to help as well as I can, but you don't cooperate.
Ok here is a screenshot of what happens. 3 graphics are missing as I had previously opened it and destroyed them
Thanks for your help

http://somup.com/cb1ZqzViwY
Thanks, absolutely amazing.

So you do this:
1) Start a new composition.
2) Drag an image from a folder on your hard drive to the body of the mail.
   Image shows.
3) No idea what you do then. Save the message?
4) Draft appears in the drafts folder.
   When viewed, the image is already not showing.
5) When edited, you have to unblock heaps of images with have
   "internal" IMAP URLs, like imap://user@domain@server>nnn?part=1.1.1.2.3&filename=xxx.jpg.

That's absolutely stunning. I have no idea how the IMAP: URL get stored in the draft. They shouldn't be stored. What should be stored is the image data, so you can see the images when viewing the draft.

I'm also surprised about the part number, typically it's 1.2 or 1.3. Hmm.

So please switch all add-ons off (see Help menu) and see whether the problem persists. Of course the "broken" draft is already broken, so please create a new one.
Thanks again for your help
I will try that later this evening and get back here
My fork of the original Quicktext, which is now what is on AMO, is:
https://github.com/rkent/Quicktext-1
Flags: needinfo?(rkent)
Hello everyone,

I'm experiencing the same issue with allowing disk files to be embedded using "SmartTemplate4", as opposed to simply clicking Reply (where the regular signature with two images shows up without complaining):

1) I'm using "SmartTemplate4" add-on where this has been set-up as HTML:

https://i.imgur.com/Yx0E1LG.png

2) The signature is referencing two files stored on disk:

<img src="file://D:/signature/oracle_sig_logo.gif" width="114" height="26" border="0">
<img src="file://D:/signature/green-for-email-sig_0.gif" width="44" height="28" align="abscenter" border="0">

3) When attempting to reply to a message, SmartTemplate4 kicks in and this happens:

https://i.imgur.com/T2VZSER.png

Considering both scenarios imply loading a signature with 2 embedded on-disk images in the HTML code, I really don't see the reason for TB's behavior.

P.S.: Nope, adding another "/" in the HTML source doesn't help.

BR,
Bogdan
Yes, the author of SmartTemplate4 needs to make sure that no file references are placed into the composition. I've advised him personally when TB 52 first came out about a year ago.

All you can do for now is to change the signature to use a data: URL. You can insert the picture into TB manually and then inspect the HTML of the compose window to copy the data: URL.

Another option would be to use the add-on from bug 1367716 which only works for new messages.
Flags: needinfo?(axelg)
Hi Jorg,

I've done exactly that, using the Base64 encode of the images :)

Cheers,
Bogdan
Status: RESOLVED → VERIFIED
Flags: needinfo?(axelg)

(In reply to sunbeam906 from comment #21)

Hi Jorg,

I've done exactly that, using the Base64 encode of the images :)

Cheers,
Bogdan

Hi - I am the author of SmartTemplate4 here - if you use the %file(...)% variable then the Add-on will do the base64 encoding for you. It seems to work well. also if you have an img with a file src in your signature, you can use %sig% in your template to include that. If you use the new (2.3) file templates and want to have the signature placed by Thunderbird you may have to replace the img source with a base64 data source to avoid triggering the warning.

I have raised the following issue for SmartTemplate4:

https://github.com/RealRaven2000/SmartTemplate4/issues/16

  • and attached a new test version that replaces file-based images in signatures with the base64 data source.
You need to log in before you can comment on or make changes to this bug.