1676825 - Remote image URL (not attached to msg) gets changed to src="filename.ext" when saving composition as *.html file (breaks recommended way of creating HTML signatures)

Status: RESOLVED FIXED

(Thunderbird :: Message Compose Window, defect)

Description

[David]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:82.0) Gecko/20100101 Firefox/82.0

Steps to reproduce:

Create or edit an html signature with images hosted on a web server (Copy-Paste or manual configuration)

File menu | Save as | Archive. "HTML files".

Actual results:

The html file does not save the images url's of the signature hosted on the web server. The "src" tags only contain the file name (as if it were local path)

This error does not allow us to edit our html signatures with current images or to create others following the user manual: File menu | Save as | Archive. "HTML files".

Expected results:

It should save the html with the url's of the images hosted on the web server.
It has always worked until these latest updates.

Comment 1

[Anje]

I'm not familiar with this: File menu | Save as | Archive. "HTML files".

In Thunderbird, using a new clean 'Write' message to create the signature file, then I use :
'File' | 'Save As' | 'File'
choose folder where I store all signature files - it's in my computer User Account - a folder called 'Signatures'.
Give file suitable name eg: formal.html
Save as type: HTML Files
Click on 'Save'

Then in Account Settings, I select the checkbox to attach the signature from a file instead and choose the saved html file.

Please confirm whether you are creating this via the above method or another.

Comment 2

[Anje]

Attachment: check-source.jpg

Test:
Tried to create signature using any image from my website.
At this initial stage I'm editing a current signature with an image from my website and checking what it looks like in a Draft message.
I highlighted the image and some text - right clicked on highlighted section as shown in website and used 'Copy'.
then I pasted into Write message below a premade signature

As you can see it also copied a small section of the webpage div info but no adverse issue.
All href and Scr info etc copied over ok

In version 68.12.1 and version 78.4.3
No problem. image displays.

Comment 3

[Anje]

re : following the user manual:
What user manual ? It would be useful to know what you were following.
Do you mean: https://support.mozilla.org/en-US/kb/signatures#w_signatures-stored-in-files

At the moment I cannot replicate the issue.

Of course, if Thunderbird was in Offline mode then it will not display image and just displays the ALT text as a clickable link.

How exactly did you copy the 'image' in the first place?
Did you highlight section on the actual webpage and use 'view selection source' and you copied that information ? Because it is likely it will not include the actual www.website address - first part of the link. Therefore it would need editing -highlight copied in text in Write window and select 'Insert' > 'HTML' , so allowing you to edit any missing code.

Without explicit information on exactly the process you performed, it is really guesswork on why you have not got the results you expected.

At this point in time, I cannot confirm that this is a bug as it still might be down to incorrect process by user.

Comment 4

[David]

(In reply to Anje from comment #1)

I'm not familiar with this: File menu | Save as | Archive. "HTML files".

In Thunderbird, using a new clean 'Write' message to create the signature file, then I use :
'File' | 'Save As' | 'File'
choose folder where I store all signature files - it's in my computer User Account - a folder called 'Signatures'.
Give file suitable name eg: formal.html
Save as type: HTML Files
Click on 'Save'

Then in Account Settings, I select the checkbox to attach the signature from a file instead and choose the saved html file.

Please confirm whether you are creating this via the above method or another.

your method is right

Comment 5

[David]

Attachment: thunderbird error step 1

Comment 6

[David]

Attachment: thunderbird error step 2

Comment 7

[David]

Attachment: thunderbird error step 3

Comment 8

[David]

Attachment: thunderbird error step 4

Comment 9

[David]

(In reply to Anje from comment #3)
Thank you Anje....
Your url of manual is OK.
Before we copied and pasted from any web page and it saved correctly in html format.
Now, the image's src (inside the html file) contains only the filename (It does not write the url of the image).
It even saves the image's src wrong if you only update a text of our current signature and save the html file again (from Thunderbird). Change the url to a local src (filename only). But before of saving the email as html file, Thunderbird shows the URL property of the image correctly.

Today, my Thunderbird has been updated with version 78.5.0 (32-bit). The problem is the same but now thunderbird save the images locally and then write the src without url:

• If the image is jpg this works but the image is stored on disk (no url).
• If the image is png then thunderbird create the local png file but windows 10 cannot recognize that png format and when opening the html file, Firefox does not show the image (format image error).

(see attached screenshots, please)

Comment 10

[Anje]

Attachment: CODEimage.jpg

The code in image shows two versions.
The first is just like your version.
I did not highlight the area. I just right clicked on image and used either 'SAve image as' or 'Copy image' to produce same results as you.

The latter shows the difference in code and now has link info.
You need to highlight the area in the webpage and then right click on highlighted area and choose 'Copy'
Then in the Write window, use Ctrl+V to paste.

So this is not a bug, but is about the method used to achieve the desired result.

Comment 11

[Richard Leger]

I can confirm this bug is reproducible and still present in TB 93.0b5 (64-bit) on Windows 10 Pro (64bits).

This is quite problematic because the 'File' | 'Save As' | 'File' | HTML Files is quite often used to create .html signature. If you compose a new email insert an image with web absolute path (eg: https://www.mydomain.com/img/image.png), when saving into .html file, only the file name (image.png) appears in the src attribute of the img tag... preventing the image to be loaded from its absolute path. This was perfectly possible in TB till recently possibly broken since 78 but not sure exact version.

Also if you had a working signature and you suddenly need to update it, then the image is lost because the absolute path that was already present in existing signature is non longer preserved upon saving :-(

Which is a bug from end-user point of view!

The reproducible method used to insert image and save signature is as follow:

• Create a New Message
• Insert > Images...
• Set Image Location as https://www.mydomain.com/img/image.png <-- change it to a valid path for your test :-)
• Set Alternative Text as Company Logo
• Ok
• File > Save As > Files...
• Set Filename as signature.html
• Set Save As Type as HTML Files

Result: Upon saving the src attribute is set to image.png instead of https://www.mydomain.com/img/image.png in the signature.html file

Workaround: Edit the .html file in text editor (e.g Notepad) and correct the src path manually then save the file which should not be required.

@Thomas,
I put you in copy for info as it may affect organisation (and other users) that use HTML signature with linked image (e.g logo) hosted centrally on a web server.

It would be great if a fix could be implemented and backported to 91.x ESR branch...

Comment 12

[Richard Leger]

Attachment: image_missing_in_signature.png

If you used the saved signature.html file for signature, it would appears as attached for both sender and recipient... basically without image :-(

signature.html file looks like this:

<html>
  <head>
    <meta http-equiv="content-type" content="text/html; charset=UTF-8">
    <title></title>
  </head>
  <body>
    <img moz-do-not-send="true" src="image.png" alt="Company Logo"
      width="168" height="102"><br>
  </body>
</html>

Instead of:

<html>
  <head>
    <meta http-equiv="content-type" content="text/html; charset=UTF-8">
    <title></title>
  </head>
  <body>
    <img moz-do-not-send="true" src="https://www.mydomain.com/img/image.png" alt="Company Logo"
      width="168" height="102"><br>
  </body>
</html>

Comment 13

[Thomas D. (:thomas8)]

Thank you Richard Leger for providing reproducible STR for this regression in comment 11. I'll fine-tune them a bit more here.
Thanks David for reporting this, and Anje for looking into this!
Alice, could you kindly find the regression range (between TB 68.12.1 and TB 78.5.0)?

Saving composition as HTML is the recommended in-app method of creating an HTML signature (see TB support article, Signatures). So it's indeed unfortunate and datalossy that this fails (although mild workarounds exist). As enterprises/organizations may be more likely to use signatures, they may be affected/irritated by this as Richard pointed out. I don't have metrics how often users save their compositions as HTML files, but losing remote references looks unexpected to me, and should be fixed (not urgent). As a start, let's find out what regressed this.

STR

1. Compose a new HTML message (e.g. with the intention of creating a company signature)
2. Insert > Image... > Location

• Specify a remote image for Image location (img src):
  E.g. https://www.thunderbird.net/media/img/thunderbird/handshake.png
• Do not check the option Attach this image to the message
• Select and specify Alternate text: E.g. "Image of handshake"

3. File > Save As > File (save to an empty folder for clarity):

• File Name: e.g. signature.html
• File Type: HTML files

4. Open the target folder where the resulting html file (signature.html) was saved, and:

• Open html file (signature.html) with a text editor, and check the image src
• Check folder for the image file (handshake.png)

Actual result

• In the generated HTML (target file, now displayed in composition), Thunderbird converted remote image URL to local relative URL, filename only
  <img src="handshake.png">
• original and intended reference to the remote image is lost (datalossy)
• Thunderbird actually downloads and saves a local snapshot copy of the remote image (handshake.png) in the same folder like the HTML file
  • which is arguably somewhat helpful, as the local HTML file will thus display correctly in a browser, even when the remote image is gone, but also
  • unexpected (e.g. because "Attach this image to the message" was not checked, nor is the file type "Webpage, complete")
  • clutter (imagine the notorious Twitter, Facebook, etc. icons all saved next to their HTML file...).
  • datalossy (see above)
  • inconvenient if used for creating HTML signatures as per TB documentation
• Somewhat surprisingly, the local image exists but will not show in composition, shows placeholder text instead (as depicted in comment 12).
• Something wrong with the compose window title, which ends in nullnull instead of local file path [file://...signature.html].

Expected result

• When saving to HTML, Thunderbird should probably preserve the original and intended full reference to the remote image src:
  <img src="https://www.thunderbird.net/media/img/thunderbird/handshake.png">
• Thunderbird should probably not save any local image files for this scenario (because "Attach this image to the message" was not checked, nor is the file type "Webpage, complete").

Comment 14

[Alice0775 White]

Regression window;
https://hg.mozilla.org/comm-central/pushloghtml?fromchange=088f530a8658a9cffb7546c9a0f014303a7aef10&tochange=17e03dc81d0d9795ee3e1027a8bbdc15f3415338
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=c38fb352aacfa6afe7fe9975fca2e777787961e8&tochange=157db696462d8a98905d0f8697088aa97cb6e08f

Comment 15

[Rachel Martin]

Fantastic work, Alice, like always, many thanks!!

Regressed by bug 1652686. Reverting
https://hg.mozilla.org/comm-central/rev/93d19e3eba91f94af9ec1be793b1bdd9353344b8#l1.20 and
https://hg.mozilla.org/comm-central/rev/93d19e3eba91f94af9ec1be793b1bdd9353344b8#l2.22
fixes the issue. There's also a TypeError: GetCurrentEditorElement().docShell.setCurrentURI is not a function in the console, likely from
https://searchfox.org/comm-central/source/mail/components/compose/content/ComposerCommands.js#1299

Comment 16

[Ben Bucksch (:BenB)]

Remote images in email are an inherent privacy problem and a bad idea.
That is particularly true for signatures, as it will trigger a warning at the receiver's side for every message, unnecessarily. Remote images should not be used in email, especially in signatures.

Comment 17

[Geoff Lankow (:darktrojan)]

We can't revert those two lines, for the reasons they were changed in the first place. You'll have to find another solution.

Comment 18

[Rachel Martin]

There seems to be a misunderstanding here: The query was not whether the two lines could be reverted. The intention was to draw the original author's attention to the regression caused, in hope of him taking care of the issue. Who exactly are you addressing with "you" in the sentence above?

Comment 19

[Rachel Martin]

A lot of stuff wrong here, or rather left-overs from SeaMonkey re. setting the window title. Likely the change in IsUrlAboutBlank() fixes the issue:
https://github.com/Betterbird/thunderbird-patches/blob/main/102/bugs/1676825-save-composition.patch

Comment 20

[:aceman]

I can see this too in TB 107, even though I do not get the 'data-original-src' attribute generated.
It only happens when the file is saved from a composition window. When saving just a displayed message, the message HTML is unchanged (just wrapped into another set of <html><body> tags which makes a very weird and potentially invalid HTML document).

Comment 21

[:aceman]

Attachment: 1676825-save-composition.patch from comment 19

The patch fixes the problem for me, but I don't understand why so I cannot review it.
One chunk needed update to apply at TB 107.

The commit message of "Fix various issues when saving composition." probably needs to be more specific.

Comment 22

[b2]

(In reply to :aceman from comment #21)

The patch fixes the problem for me, ...

It also fixes the "nullnull" display in the window title, see comment #13. Removal of SetDocumentURI() is due to the fact that it fails anyway, see comment #15. return urlString.startsWith("about:blank"); fixes the save problem.

Comment 23

[Richard Leger]

(In reply to Ben Bucksch (:BenB) from comment #16)

Remote images in email are an inherent privacy problem and a bad idea.
That is particularly true for signatures, as it will trigger a warning at the receiver's side for every message, unnecessarily. Remote images should not be used in email, especially in signatures.

From a business and marketing point of view, signature may contain images (e.g logo) that is a fact and a genuine request from a lot of organisation out there to smooth their communications with recipients when communicating by email. So not having possibility of image in signature is not an option.

Some organisation make the choice to use a remote image instead of an embedded one because it easily ensure that all signatures use the same one as well as prevent the image to be duplicated and embedded in every email sent by the company which is using storage space at every de-duplication, and therefore a waste. Using a remote source image prevent that in the first place as well.

While there may be some concern in term of privacy in some cases and circumstances, for most usage there isn't as genuine business may genuinely want their clients to see their logo in signature via a remote image without concern for privacy.

As you said receiver has the choice or not to accept this image to be displayed or not for the current message received or all received after from a trusted source. So privacy concern can be handled by end-user control and mechanism already in place.

Therefore there is absolutely no reason to prevent TB end-users to use remote image in signature would they want/prefer to an embedded image. This should be a user choice not a developer choice to impose a solution to a problem which is not necessarily one for a majority of people...

You can raise concerns and awareness via notification and message alert... but it must remain a user choice...

Currently preventing the usage of remote image in signature is more a problem to end-users than the privacy concerns you raise...

Why to break then not fixed what as worked fine till now... I am wondering...

Regards,

Comment 24

[Magnus Melin [:mkmelin]]

Comment on attachment 9296122 [details] [diff] [review]
1676825-save-composition.patch from comment 19

Review of attachment 9296122 [details] [diff] [review]:
-----------------------------------------------------------------

Seems to work, r=mkmelin

Comment 25

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/98dfebcdd09d
Fix editing remote remote url of images and saving the result as html. r=mkmelin