Open Bug 992633 Opened 11 years ago Updated 2 years ago

Mime type of image is text/plain in HTML mail when drag-dropped from Nautilus into content (Tb uses "data:;base64,/9j/4AAQSkZJRgABAgE..." as Image Location when Drag&Drop from Nautilus)

Categories

(MailNews Core :: MIME, defect)

Product:
MailNews Core
Component:
MIME
Platform:
x86_64
Linux
Type:
defect

Tracking

(Not tracked)

People

(Reporter: kloor68373, Unassigned)

References

Details

Attachments

(1 file)

Bildschirmfoto vom 2014-04-09 14:05:25.png
39.70 KB, image/png
Details
User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:28.0) Gecko/20100101 Firefox/28.0 (Beta/Release) Build ID: 20140317233623 Steps to reproduce: 1. Created a new HTML mail with TB on Linux (Mint 13). Error does not occur on Windows TB. 2. Drag-dropped an image (jpeg or png) from file manager Nautilus V3.4.2 into content area (not: attachment area). You can use different versions of TB/Nautilus too. 3. Sent mail to myself 4. View received mail with other clients. 5. Looked into source code of received mail. Actual results: 1st Error: Mime type of mail (composed the way described above) contains the image base64 coded but mime type is not stated correctly (text/plain; charset=ISO-8859-15 instead of image/jpeg or image/png) ============================== ... This is a multi-part message in MIME format. --------------080301060603070806020001 ... --------------080301060603070806020001 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: base64 ... ============================== 2nd Error: Image is displayed "correctly" on TB. Other mail clients reveal image as corrupted but I do not realize this fact when I look at my faulty mail in sent folder. Expected results: 1. Content-Type of image should be stated correctly as image, not text when dragged-dropped from file manager on Linux. 2. When receiving images with incorrect mime types they must be revealed as corrupted. Mime types may not be guessed/corrected by TB, only the given mime type may be applied.
Same problem as Bug 989621? (see data in bug 989621 comment #7) What is shown as "Image Location" just after Drag&Drop, after draft save, second draft save?
The "Image Location" ist not the problem which I describe. My reported issue concerns the content type of an image, stored as a multipart section.
I never say that "Image Location" is the problem which you described. I asked you about "Image location" which Tb used by your Drag&Drop operation. Have you actually read and understand that bug which I pointed? Have you checked content in the text/html part with base64 encoded which is generated by Tb? Save as draft, copy saved draft to .eml file, edit .eml file by Text editor, change multipart/related to multipar/mixed, change text/html to text/plain, drag&drop .eml file to thread pane of a local mail folder(import .eml by Drag&Drop) What is shown for the text/plain part? (originally text/html which was geerated for image) Can you see your problem by following? Insert Image, Choose file, select an image file via file picker? I think answer is No, because "Image Location" starts with "file:///abc/def/filename.jpg" like one in this case. Bug 871873 is also an "Image Location by Drag&Drop" related problem. > Bug 871873 - dragging JPG image into TB compose window inserts as inline BMP You can see that bug by simply do following. View local .jpg file by SeaMonkey, Drag&Drop shown image to Tb's HTML composition window. => Image Location = data:image/x-bmp;base64,...
(In reply to kloor68373 from comment #0) > 2nd Error: > Image is displayed "correctly" on TB. Other mail clients reveal image as corrupted In bug 989621, following is observed. 1. Compose, Insert Image, or Copy&Paste Image, first draft save #1 => Image is shown at compose window => Image in saved draft is visible by Tb. i.e. data is image data 2. draft save #2 => Image is broken at compose window => Image in saved draft is still visible by Tb. i.e. data is image data 3. draft save #3 => Image is broken at compose window => Image in saved draft is broken. i.e. data is not image data Mail data stream generated by Tb is same in "Send without draft save" and "first draft save". Tb has Quirks on "text/html with image data", or Tb does "content sniffing" because it's defined in HTML 5. I guess it's by "content sniffing" in Tb.
(In reply to kloor68373 from comment #0) > Steps to reproduce: > 2. Drag-dropped an image (jpeg or png) from file manager Nautilus V3.4.2 > into content area (not: attachment area). You can use different versions of TB/Nautilus too. If "Drag&Drop Image from Broweser to Tb on Win", bug 871873 occurs. If "Drag&Drop file(s) from File Manager(Windows Explorer) to Tb on Win", or "Copy at Windows Explorer, Paste at Tb on Win", "Image location" starts with "data: image/jpeg,base64, ...", and no problem occurs. "text/html for embed image" is seen only when file URI or http/https URI. It looks "Drag&Drop file(s) between Nautilus/Tb on Linux" is "pass file path to Tb(path file URL)", instead of "pass file data to Tb(path image data via data: URI)".
Settig dependency to bug 989621 for ease of problem analyis and trcking.
Depends on: 989621
(In reply to kloor68373 from comment #0) > 2nd Error: > Image is displayed "correctly" on TB. Other mail clients reveal image as corrupted Unable to reproduce it with test case for bug 989621 on Win-XP. If image is viewable by Tb, image part was always image/jpeg and data is correct image data. If image is not viewable by Tb, image part was always text.html, and dataa is also broken. When, at which panel or window, with what operation, did you see "Image is displayed *correctly* on TB", even though Other mail clients reveal image as corrupted? 0. View a local image file by SeaMonkey, with excess hash/query part in file URL. file:///C:/wada/@@@/Data/JpegFile.jpg#abc?xyz This is to force "url with hash/query for image data". 1. Copy Image at SeaMonkey, Paste at Tb's HTML compose window. Image Location : file:///C:/wada/@@@/Data/JpegFile.jpg#abc?xyz Image is shown at compose widow. Save as draft #1 => part = imae/jpeg, data is correct => image is shown by view draft mail Image Location is not changed by draft save #1, and image is shown after draft save #1 2. Save as draft #2 => part = imae/jpeg, data is correct => image is shown by view draft mail However, after save as raft #2, image is broken at compose window, and Image Location is changed to mailbox:///C:/　 ... /Mail/pop.ops.dti.ne.jp/Drafts?number=373912&xyz 3. Save as draft #3 => part = text/html, part data is broken => image is broken by view draft mail after it, following cotinuesafter each save, or Send Later, or Send. image is broken at compose window after save. image part = text/html in saved draft, sent mail, datt of image part is broken(html data is base64 encoded), Image Location is always mailbox:///C:/　... /Mail/pop.ops.dti.ne.jp/Drafts?number=NNNNNN&xyz 　　　　(NNNNNN=messageOffset is changed uon each saved as draft) To bug opener: How, where did you see following phenomenon? > 2nd Error: > Image is displayed "correctly" on TB. Other mail clients reveal image as corrupted
> What is shown as "Image Location" just after Drag&Drop, from image properties (double click image, first item within first tab) data:;base64,/9j/4AAQSkZJRgABAgE... > after draft save, same > second draft save? same Additional: File /home/xxz/.thunderbird/Drafts shows X-Mozilla-Draft-Info: internal/draft; vcard=0; receipt=0; DSN=0; uuencode=0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 Content-Type: multipart/related; boundary="------------000504080209060303040809" This is a multi-part message in MIME format. --------------000504080209060303040809 Content-Type: text/html; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit <html> <head> <meta http-equiv="content-type" content="text/html; charset=ISO-8859-15"> </head> <body text="#000000" bgcolor="#FFFFFF"> <img src="cid:part1.09060602.00080508@xyz.com" alt=""><br> <br> <br> <br> </body> </html> --------------000504080209060303040809 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: base64 Content-ID: <part1.09060602.00080508@xyz.com> /9j/4AAQSkZJRgABAgEAZABkAAD/4Q6kRXhpZgAATU0AKgAAAAgABwESAAMAAAABAAEAAAEa ...
> Can you see your problem by following? > Insert Image, Choose file, select an image file via file picker? > I think answer is No, because "Image Location" starts with "file:///abc/def/filename.jpg" like one in > this case. No problem. Adresss is file:///home/xyz/Bilder/O... Drafts file shows X-Mozilla-Draft-Info: internal/draft; vcard=0; receipt=0; DSN=0; uuencode=0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 Content-Type: multipart/related; boundary="------------090706070209020008060905" This is a multi-part message in MIME format. --------------090706070209020008060905 Content-Type: text/html; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit <html> <head> <meta http-equiv="content-type" content="text/html; charset=ISO-8859-15"> </head> <body text="#000000" bgcolor="#FFFFFF"> <img alt="" src="cid:part1.09030700.07060609@xyz.com" height="380" width="620"> </body> </html> --------------090706070209020008060905 Content-Type: image/jpeg; name="O...jpg" Content-Transfer-Encoding: base64 Content-ID: <part1.09030700.07060609@xyz.com> Content-Disposition: inline; filename="O...jpg" /9j/4AAQSkZJRgABAgEAZABkAAD/4Q6kRXhpZgAATU0AKgAAAAgABwESAAMAAAABAAEAAAEa
> Tb has Quirks on "text/html with image data", or Tb does "content sniffing" because it's defined in > HTML 5. I guess it's by "content sniffing" in Tb. I think it is no good idea to sniff content instead of using given content-type description. Sniffing content would be useful if no content-type is given or to verify given content-type and show an error image if they do not match. But to overwrite a stated content-type does not sound compliant to standard to me.
> Unable to reproduce it with test case for bug 989621 on Win-XP. As mentioned in description the error occurs on linux port only
> To bug opener: > How, where did you see following phenomenon? > > 2nd Error: > > Image is displayed "correctly" on TB. Other mail clients reveal image as corrupted I sent the mail to a friend who uses outlook. she said the images are not displayed. I looked into my sent folder and saw the images displayed well. So I looked into the source code and discovered the false content type desciption (as inserted some comments above: > Content-Type: text/plain; charset=ISO-8859-15 > Content-Transfer-Encoding: base64
I could reproduce the error reliably on every (3/3) computer with different linux mint versions. Have you got problems reproducing the error? Do you need some additional information about how to reproduce it?
(In reply to kloor68373 from comment #8) > > What is shown as "Image Location" just after Drag&Drop, > from image properties (double click image, first item within first tab) > data:;base64,/9j/4AAQSkZJRgABAgE... No string between "data:" and ";base64,"? i.e. mime-type field in data: URL == null(string of length=0)
(In reply to WADA from comment #14) > (In reply to kloor68373 from comment #8) > > > What is shown as "Image Location" just after Drag&Drop, > > from image properties (double click image, first item within first tab) > > data:;base64,/9j/4AAQSkZJRgABAgE... > No string between "data:" and ";base64,"? > i.e. mime-type field in data: URL == null(string of length=0) I copied the text via clipboard. Screenshot will folow.
> (In reply to kloor68373 from comment #8) > > > What is shown as "Image Location" just after Drag&Drop, > > from image properties (double click image, first item within first tab) > > data:;base64,/9j/4AAQSkZJRgABAgE... > No string between "data:" and ";base64,"? > i.e. mime-type field in data: URL == null(string of length=0) > (comment #15) I copied the text via clipboard. > (comment #16) attachment 8403937 [details] Bildschirmfoto vom 2014-04-09 14:05:25.png http://en.wikipedia.org/wiki/Data_URI_scheme Format data:[<MIME-type>][;charset=<encoding>][;base64],<data> If <MIME-type> is omitted, it defaults to text/plain; If the data: URI is generated by Nautilus, BUG in Tb is that "Content-Type: text/html" is generated instead of correct "Content-Type: text/plain".
"Generated Content-Type: text/html" part is same as bug 989621, but this bug is "data: URI" case. Setting dependency to Bug 871873 for ease of analysis.
Depends on: 871873
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Mime type of image is text/plain in HTML mail when drag-dropped from Nautilus into content → Mime type of image is text/plain in HTML mail when drag-dropped from Nautilus into content (Tb uses "data:;base64,/9j/4AAQSkZJRgABAgE..." as Image Location when Dra&Drop from Nautilus)
Generated Content-Type: was text/plain. Sorry for my confusing.
No longer depends on: 989621
As written in bug 871873, "mime-type in data: URI of Tb" is obtained from event.dataTransfer["files"][0]["type"] property in event object which is passed to Drop handler of composer of Tb. [type] = image/jpeg => Content-Type: image/jpeg : usual [type] = image/bmp => Content-Type: image/bmp : original problem of bug 871873 [type] = image/x-bmp => Content-Type: image/x-bmp : found in bug 871873, passed from SeaMonkey [type] = null => data:;base64... => default=text/plain => Content-Type: text/plain : your case In any case, "image data for the part" is read from proper file, so "data in the part" itself is valid/proper image data. So, if image/bmp and image/x-bmp is processed as "displayable image" by mailer, image is shown, and even when text/plain, is "content sniffing defined by HTML 5" is applied, image is shown by mailer. For your case. Nautilus says "it's text/plain" by "null in type", so Tb puts it in Content-Type:. What's wrong?
Summary: Mime type of image is text/plain in HTML mail when drag-dropped from Nautilus into content (Tb uses "data:;base64,/9j/4AAQSkZJRgABAgE..." as Image Location when Dra&Drop from Nautilus) → Mime type of image is text/plain in HTML mail when drag-dropped from Nautilus into content (Tb uses "data:;base64,/9j/4AAQSkZJRgABAgE..." as Image Location when Drag&Drop from Nautilus)
Obviously the error originates from Nautilus' empty mime type property in its drop event data. So we could pass the bug to Nautilus' authors and close this item. BUT Thunderbird's behaviour is not consistent in this case: * On the one hand, when receiving a dropped image from Nautilus without mime type speciifcation it default to plain text * On the one hand, when receiving a multipart frame it ignores the stated content type and guesses itself (and herewith hides the existence of a wrongly stated content type) I would propose a behaviour just the other way round: * If no mime type is given (from Nautilus or whomsoever) TB performs content sniffing to find it out * If a mime type is given in a multipart frame, Nautilus should try to render data according to this stated type. If this fails, it still has the benefit to find out flawed composing source. In the long way it's better to reveal than to hide errors. So I do approve Outlook's behaviour even if I'm no friend of this piece of software. Solved in latter way we can go on using TB to create compliant Mails that can be displayed by every mail client expectably. Nevertheless I will report this error to Nautilus tracker, too.
Problem in Tb is: When Drag&Drop, Tb blindly uses files[0] currently, with ignoring facts that (i) some browsers passes "BMP data in temp file used for image dsplay, with image/bmp", and (ii) some other older browsers passes "BMP data in temp file used for image dislay, with image/x-bmp". Because Tb blindly uses files[0] always if Drag&Drop, this bug occurs. If file: URI is used upon Drag&Drop, this bug won't be exposed. I believe that default of event.dataTransfer["files"][N]["type"] is not defined. Default=text/plain is officially applicable to only (a) Content-Type: header and (b) data: URI.. So, I believe "conversion from mime-type=null to mime-type=text/plain" was made by Tb. Because ["files"][0]["type"]=null, Tb checks file extention and/or file content. Because file is jpeg file, Tb accepts it as "Drag&Drop of image file" During "Insert Image" process, Tb converts passed file data to data: URI. Upon conversion to data: URI, Tb puts null from ["files"][0]["type"] as "mime part" of data: URI. Because "default mime-type of data: URI"==text/plain, "translating 'null' to 'text/plain'" completes at here. If 'default of event.dataTransfer["files"][N]["type"]==text/plain' is applied by Tb, Tb should ignore this file. If Tb accepts "file with type=null" as "image file" based on "file extention", Tb should generate mime-type if type=null is passed from Drag initiator. I believe following is solution of both "type=image/bmp(or x-bmp) for originally jpeg file" case and "type=null for image file" case. Stop blind use of event.dataTransfer["files"][0]. If mismatch between data in event.dataTransfer["files"][0] (type, file extension) and data obtained by event.dataTransfer.getData("text/x-moz-url") is found, and URL of file is file: URL, and ["files"].length==1, Use the file: URL. Procedure I proposed in bug 871873 is this solution. Note: If http:/https: URL, "use event.dataTransfer["files"][0] always" may be better, because there is no need to issue HTTP GET by Tb. For consistecy among Drag&Drop, Copy&Paste, Insert Image by URL, and for "snap shot upon insert/attach operation", current "conversion to data: URI from event.dataTransfer["files"][0]", which is used in Drag&Drop, may be better portd as "conversion to data: URI from any URL/file name" to all Drag&Drop, Copy&Paste, Insert, Attach operation.
Nautilus' issue not providing a content type description was reported to GNOME tracker: https://bugzilla.gnome.org/show_bug.cgi?id=728081 Bug 728081 - Drop handler receives empty type property when image is dragged from Nautilus to Thunderbird
Result applying WinBackMyTrash-0-1-0-016 was: ----------------------------------------------------- 2014/04/15 10:45:43.502 GMT WinBackMyTrash#1 Drop event at iD=button-newmsg, event.dataTransfer = { [dropEffect] = move [effectAllowed] = uninitialized [files] = { [0] = { [size] = 124947 [type] = image/jpeg [slice] = function slice() [mozSlice] = function mozSlice() [name] = xxxxxxxxxxxxxxxxxxxxxx.jpg [lastModifiedDate] = Wed Apr 09 2014 09:55:25 GMT+0200 (CEST) [mozFullPath] = /home/xxxxxxxxxxxxxxxxxxxxxx.jpg } [item] = function item() [iterator] = function iterator() [length] = 1 } [types] = { [0] = application/x-moz-file [1] = text/x-moz-url [2] = text/plain [3] = Files [length] = 4 [item] = function item() [contains] = function contains() } [clearData] = function clearData() [setData] = function setData() [getData] = function getData() [setDragImage] = function setDragImage() [addElement] = function addElement() [mozItemCount] = 1 [mozCursor] = auto [mozTypesAt] = function mozTypesAt() [mozClearDataAt] = function mozClearDataAt() [mozSetDataAt] = function mozSetDataAt() [mozGetDataAt] = function mozGetDataAt() [mozUserCancelled] = false [mozSourceNode] = null } ----------------------------------------------------- 2014/04/15 10:45:43.712 GMT WinBackMyTrash#1 event.dataTransfer.getData() for types = { [application/x-moz-file] = [text/x-moz-url] = file:///home/xxxxxxxxxxxxxxxxxxxxxx.jpg [text/plain] = file:///home/xxxxxxxxxxxxxxxxxxxxxx.jpg [Files] = } ----------------------------------------------------- 2014/04/15 10:45:43.712 GMT WinBackMyTrash#1 event.dataTransfer.getData() Special = { [URL] = } --------------
(In reply to kloor68373 from comment #25) > [type] = image/jpeg > [mozFullPath] = /home/xxxxxxxxxxxxxxxxxxxxxx.jpg Do you see text/plain for Inserted Image part in draft mail, mail after Send Later? Do you see entry for .jpg, image/jpeg, text/plain in your mimeTypes.rdf under Profile Directory? Is "image/jpeg" set when the file is attached? Is "/home" == home directory under root directory named "/" in file system? (I think absolute path like /home/<userame>/... is usually used hor "user's home directory".) Does "/home in absolute style file path" have special meaning in any place on any Linux?
(In reply to WADA from comment #26) > (In reply to kloor68373 from comment #25) > > [type] = image/jpeg > > [mozFullPath] = /home/xxxxxxxxxxxxxxxxxxxxxx.jpg > > Do you see text/plain for Inserted Image part in draft mail, mail after Send > Later? I see it in draft mail source view (in "drafts" on local folder): Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: base64 Content-ID: <part1.06060500.04040302@xyz.com> in received mail source view: Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: base64 Content-ID: <part1.04060709.08010006@xyz.com> > Do you see entry for .jpg, image/jpeg, text/plain in your mimeTypes.rdf > under Profile Directory? I cannot "locate" any mimeTypes.rdf, only in firefox folders. But this issue has nothing to do with FF. > Is "image/jpeg" set when the file is attached? attachments works, even when created drag-dropping Content-Type: image/jpeg; name="xxxxxxxxxxxx.jpg" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="xxxxxxxxxxxx.jpg" > Is "/home" == home directory under root directory named "/" in file system? > (I think absolute path like /home/<userame>/... is usually used hor "user's > home directory".) my home dir is named /home/<userame>/ but i shortened it to obscure any information of company computers > Does "/home in absolute style file path" have special meaning in any place > on any Linux? my file name is /home/<username>/Bilder/<filename>.jpg i shortended it to /home/xxxxxxxxxxxxxxxxxxxxxx.jpg to obscure username I'm using standard path names for home and TB install dirs on all of the 3 computers i've done tests for my reports. There are no modified file or dir permissions.
Does > [size] = 124947 > [type] = image/jpeg > [slice] = function slice() > [mozSlice] = function mozSlice() > [name] = xxxxxxxxxxxxxxxxxxxxxx.jpg > [lastModifiedDate] = Wed Apr 09 2014 09:55:25 GMT+0200 (CEST) > [mozFullPath] = /home/xxxxxxxxxxxxxxxxxxxxxx.jpg mean that TB receives correct mime type and I have to revoke my Nautilus bug report https://bugzilla.gnome.org/show_bug.cgi?id=728081 "Drop handler receives empty type property when image is dragged from Nautilus to Thunderbird"?
Please consider that WinBackMyTrash's trace was taken during drag/drop on new message *button* as described in http://www.h2.dion.ne.jp/~radon/mozilla/tb-addon/WinBackMyTrash-0-1-0-DragDrop.html "If you want to dump event.dataTransfer content to Error Console, do Drop at Compose button(new message) button." not on composer's pane. This might result in different behaviour - drag/drop on attachment area works, too.
(In reply to kloor68373 from comment #27) > my file name is > /home/<username>/Bilder/<filename>.jpg > is shortended it to > /home/xxxxxxxxxxxxxxxxxxxxxx.jpg > to obscure username If so, how can an application program or a program/script code distinguish or isolate /home/<username>/Bilder/xxxxxxxxxxxxxxxxxxxxxx.jpg and /home/xxxxxxxxxxxxxxxxxxxxxx.jpg on your Linux? /home/xxxxxxxxxxxxxxxxxxxxxx.jpg is not actual absolute full path in file system of OS? If so, is 'event.dataTransfer.["mozFullPath"] = /home/xxxxxxxxxxxxxxxxxxxxxx.jpg' correct? Note: This ["mozFullPath"] is set by Tb upon first DragOver event at Tb's window from event.dataTransfer object which was passed from Drag&Drop processor of OS. (In reply to kloor68373 from comment #29) > Please consider that WinBackMyTrash's trace was taken during drag/drop on new message *button*. > "If you want to dump event.dataTransfer content to Error Console, do Drop at Compose button(new message) button." OK. I'll try to implement "Dump event.dataTransfer" upon Drop at composition window, althouh I don't think there is diffrence in event.dataTransfer content between "Drop at New Message button" and "Drop at Compose window". If problem exists, I suspect that problem is in "Object referred by Insert Image code which is not native event.dataTransfer object in Tb". I'll try to implement dump of "Object referred by Insert Image code" after Drop of the image file.
(In reply to WADA from comment #30) > (In reply to kloor68373 from comment #27) > > my file name is > > /home/<username>/Bilder/<filename>.jpg > > is shortended it to > > /home/xxxxxxxxxxxxxxxxxxxxxx.jpg > > to obscure username > > If so, how can an application program or a program/script code distinguish > or isolate /home/<username>/Bilder/xxxxxxxxxxxxxxxxxxxxxx.jpg and > /home/xxxxxxxxxxxxxxxxxxxxxx.jpg on your Linux? > /home/xxxxxxxxxxxxxxxxxxxxxx.jpg is not actual absolute full path in file > system of OS? I hope I did not confused you. There has never been a filename with absolute path /home/xxxxxxxxxxxxxxxxxxxxxx.jpg or a name xxxxxxxxxxxxxxxxxxxxxx.jpg All xxxx or xyz names in my posts are the result from my manually obscuring file and dir names. Filenames always had the proper format /home/<username>/Bilder/<imagename>.jpg
Drag&Drop in composer utilizes wrapper for Drag%Drop, Paste from ClipBoard etc. > http://mxr.mozilla.org/comm-central/source/mail/components/compose/content/MsgComposeCommands.js#4105 > http://mxr.mozilla.org/comm-central/source/mozilla/toolkit/content/nsDragAndDrop.js#25 Flavor etc. is set from event.dataTransfer etc. So I think "image/jpeg" in dump of event.dataTransfer["files"][0][type] is correctly passed to composer. Following is a routine for "Conversion from full-path to DataURL". > http://mxr.mozilla.org/comm-central/source/mozilla/content/base/src/nsDOMFileReader.cpp#526 Mime-type is set by aFile->GetType. i.e. In Linux & Win, mime-type of DataURL set from file extension. In Linux, file extension is not case-insensitive in some places. Relation between "file extention and mime-type" is obtained from; 1. mimeTypes.rdf, 2. Tb's internal table/hard coded string, 3. registered data to OS ( Win example of 3. HKEY_CLASSES_ROOT\.jpg in Windows Registory ) No problem in such registration in your environment?
File type jpeg is registered correctly in my desktop environment (not: os, because on Linux there is a proper separation of operating system, desktop environment and file manager). I can open .jpg files with xdg-open. Their types are also shown correctly in Nautilus regardless wether I rename it to A.jpg A.jpeg, A.JPG, A.JPEG or even A. But in the latter case ("A") drag and drop from nautilus will fail, no image is inserted into composer. In the other mentioned notations it results in an image with stated content-type text/plain. Maybe that's an interesting information for you.
(In reply to kloor68373 from comment #33) > File type jpeg is registered correctly in my desktop environment (not: os, > because on Linux there is a proper separation of operating system, desktop > environment and file manager). Does it mean that /etc/mime.types like one is not referred any more on any Linux, with any Desktop environment, with any File Manager, by any application? > https://help.ubuntu.com/community/AddingMimeTypes > https://wiki.archlinux.org/index.php/xdg-open#mimetype > http://docs.kde.org/stable/en/kde-runtime/kcontrol/filetypes/index.html
Depending on desktop env and application there are different sources for association of filename extensions, mime types, icons, preferred applications, magic numbers and all that stuff. But besides * /etc/mime.types there are also (I googled) * /usr/share/mime/ * ~/.local/share/mime/ * ~/.local/share/applications/ Some applications (eg. Subversion clients) even use their own mime type definitions, independently of host's settings. I'm no specialist in that subject and I think it's not simple and has many aspects, too. So I don't know which of all those sources are used or should be used by TB. Sorry. But considering Nautilus seems to pass the correct mime type, why not simply make use of it?
> But considering Nautilus seems to pass the correct mime type, why not simply make use of it? I guess : mime-type in event.dataTransfer was unreliable in the past. "definition of file extension -> mime-type in OS" was far reliable, especially on Win :-) Because Tb has bug 503309, broken mimeTypes.rdf can be pretty easily generated. 1. Create mail with attachment, for example, Content-Type: image/bmp, filename="xxx.bmp". 2. Change to Content-Type: abc/def, Repair Folder 3. Open attachment by an applicatio, with "Do this always" => association between "file extension=bmp" and "mime-type=abc/def" is generated in mimeTypes.rdf. 4. Change "abc/def" in mimeTypes.rdf to "image/", restart Tb. Drag image(png) shown by SeaMonkey to to Tb's HTML composer. (SeaMonkey passes BMP data, HKEY_CLASSES_ROOT\.bmp=image/bmp, image/bmp event.dataTransfer) => data:image/;base64,iVBOR... Send Later => Content-Type: image/; name="bgidjgaa.bmp" Content-Disposition: inline; filename="bgidjgaa.bmp" Because "Content-Type: image/" has no subtype, it's not shown as embed image. Shown as attachment, because this part is not displayed. 5. Change "abc/def" in mimeTypes.rdf to ""(null), restart Tb. Drag image(png) which is shown by SeaMonkey to to Tb's HTML composer. => data:XPConnect JavaScript;base64,Qk2KE... Because of "null", text by internal String(an object) was set. This may be Win only phenomenon. => Because "XPConnect JavaScript;" is fortunately perfectly broken, Content-Type: image/bmp is fortunately set in mail, so image is shown as embed image. Is "data:;base64,Qk2KE..." reproducible by broken mimeTypes.rdf entry on Linux?
Needless to say, if data:XPConnect JavaScript;base64,Qk2KE... of Image Location is changed to data:;base64,Qk2KE... manually, following is generated, and image is shown as embed image of HTML mail by Tb. > --------------030101090202050106070605 > Content-Type: text/plain; charset=ISO-8859-1 > Content-Transfer-Encoding: base64 > Content-ID: <part1.03090501.08090902@ops.dti.ne.jp>
(In reply to WADA from comment #36) > Is "data:;base64,Qk2KE..." reproducible by broken mimeTypes.rdf entry on > Linux? $ locate -i mimeTypes.rdf /etc/skel/.mozilla/firefox/mwad0hks.default/mimeTypes.rdf /home/<username>/.mozilla/firefox/mwad0hks.default/mimeTypes.rdf There is no mimeTypes.rdf on my computer execpt those in FF's dirs.
(In reply to kloor68373 from comment #38) > There is no mimeTypes.rdf on my computer execpt those in FF's dirs. If no entry, I think Tb on Linux doesn't create useless null mimeTypes.rdf file. Create crafted entry, with a crafted mail, as I described in comment #36, please.
Component: Untriaged → MIME
Product: Thunderbird → MailNews Core

I believe I'm experiencing this issue, too. See https://github.com/mganss/AttachFromClipboard/issues/2
The add-on is at https://addons.mozilla.org/thunderbird/addon/attach-from-clipboard/
The application/x-moz-file flavor is added before the text/plain flavor, yet text/plain is returned when calling nsITransferable.getAnyTransferData() on Linux. It works fine on Windows.

Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: