Open Bug 1356918 Opened 7 years ago Updated 2 years ago

TB composer loses extensions in filename of an image set as page background

Categories

(Thunderbird :: Message Compose Window, defect)

x86_64
Linux
defect

Tracking

(Not tracked)

People

(Reporter: aceman, Unassigned)

References

Details

+++ This bug was initially created as a clone of Bug #1356245 +++

When composing a message in HTML format and adding a local image into the background of the page/message (not an embedded image in <img> tag), Thunderbird always attaches this image in the message with a random filename and without any extension (even if the original file had one). In this example a an image.gif was set (notice the Content-Type):

Content-Type: image/gif;
 name="ollcghhmddkehocj."
Content-Transfer-Encoding: base64
Content-ID: <part1.64AF61B0.23B216B5@domain.sk>
Content-Disposition: inline;
 filename="ollcghhmddkehocj."

Now saving this composition as draft and reopening it, will analyse the filename and without extension it will be changed to image/png via patch in bug 1356245.

The point of this bug is to find out why this happens as TB should have the full filename at its disposal (it opened it from the filesystem).

In contrast, embedding the same image via an <img> tag keeps the correct filename and extension intact. So TB seems to take different paths when inserting and embedded image (<img>) and a page background (<body background="">).

For me this happens with all images set as background (whether gif or png).
I observed this on Linux.
Not seen on Windows. Starting with roses.gif I get this in the body:

<body vlink="#551A8B" text="#000000" link="#0B6CDA" bgcolor="#FFFFFF"
background="data:image/gif;base64,…[1]"
(data: URL shortened by ThunderHTMLedit)

and this in the stored draft:

Content-Type: image/gif;
 name="pokkjpbbfpimjfci.gif"
Content-Transfer-Encoding: base64
Content-ID: <part1.5DDF15BB.B685632B@jorgk.com>
Content-Disposition: inline;
 filename="pokkjpbbfpimjfci.gif"
Yes, it may be OS specific. But at least you also see the random filename, which doesn't happen for <img>.
For embedded images, the conversion happens in the code you just fixed:
https://hg.mozilla.org/comm-central/rev/27b2d3f67fe4019f4deb2d50d1b8360fefe7e09a#l1.25

For backgrounds, it's done here:
https://dxr.mozilla.org/comm-central/rev/e2a93f33a9826ae2039589d25ed0ea6bde13dbf9/mail/components/compose/content/EdColorPropsOverlay.xul#28

The former uses a binary input stream with a hand-crafted URL including "filename=", the latter one a file reader and .readAsDataURL() which doesn't add "filename=". Hence, MIME invents a random filename for the attachment, but it really should add a file extension on all platforms.

We also use .readAsDataURL() here:
https://dxr.mozilla.org/comm-central/rev/e2a93f33a9826ae2039589d25ed0ea6bde13dbf9/mail/components/compose/content/MsgComposeCommands.js#2355

That code is executed when you paste HTML from MS Word (or a local .html document) that includes a file: URL referencing a file in the temp directory which is less than 60 seconds old. That was done to pastes from MS Work would continue to work.

We could insert our "filename=" at these call sites.
Grammar: That was done *so* pastes from MS Work would continue to work.
(In reply to Jorg K (GMT+2) from comment #3)
> We could insert our "filename=" at these call sites.
Aceman, could you try this?
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.