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)
Tracking
(Not tracked)
NEW
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.
Comment 1•7 years ago
|
||
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>.
Comment 3•7 years ago
|
||
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.
Comment 4•7 years ago
|
||
Grammar: That was done *so* pastes from MS Work would continue to work.
Comment 5•7 years ago
|
||
(In reply to Jorg K (GMT+2) from comment #3) > We could insert our "filename=" at these call sites. Aceman, could you try this?
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•