User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:20.0) Gecko/20100101 Firefox/20.0 Build ID: 20130409194949 Steps to reproduce: From Firefox 20.0.5 32 bit Windows virgin account (no extensions), dragging JPG image into TB virgin account (no extensions) compose window Example: http://www.vitaminlife.com/images/products/huge/033674632000.jpg Actual results: the image gets inlined as BMP. Resulting Problems: 1. not all (if not most) email clients display .bmp 2. inlined grfx and therefore sent email size is unnecessarily high Expected results: .jpg image should be inlined as jpg This works fine if the .jpg is dragged from Internet Explorer 9.0.15 32 bit (Windows 7 64bit). Therefore I consider this rather a Firefox than a Thunderbird bug

1. I'm running 32 bit versions of both TB & FF in my Win7 64. 2. when dragging the .JPG from FF to Desktop or Explorer, the extensions correctly remains .jpg --> seems we're dealing with a drag/drop miscommunication betw. TB & FF here. 3. I changed priority because recipients cannot see these images 4. Workaround: a) in FF, copy URL b) in TB, Insert/ Image/ paste image URL

Looks like bug 557708 which I've filed a couple of years ago now also affects images drag-and-dropped into the message body? See bug 557708 comment #4 and following.

Just another datapoint: Drag and drop a .jpg from the windows explorer window works correctly. So this would seem to be a Firefox problem rather than TB

Bug remains the same with FF 21 & TB 17.06 --> <img src="data:image/bmp;base64,Qk0K .... @ rsx11m: wow, so we're dealing with a 3 yr old bug here? In general it does not make sense a) why the source format is not maintained and b) the source URL <img src="http://...jpg"> @ Joe: confirmed, and agreed

PS: @ rsx11m: I am aware that bug 557708 is not exactly the same (attachment), but the action (drag & drop) is the same.

I'm tempted to confirm this, but the relationship with bug 557708 isn't entirely clear to me yet. That bug indeed occurred at least 3 yrs ago, but at that time, drag-and-drop from Firefox into a Thunderbird composition still worked and passed a reference, with Thunderbird downloading the image directly from the web site (I definitely had tried this). So, this appears to be a more recent regression (also indicative that reports about drag-and-drop into the message window producing large BMP inlined attachments didn't show up earlier).

(In reply to Lee Binder from comment #1) > 4. Workaround: > a) in FF, copy URL > b) in TB, Insert/ Image/ paste image URL Interesting: right-click on the image > Copy Image in Firefox 21.0, the pasting into Thunderbird 17.0.6 produces the previous behavior with pasting a reference <img src="http:..."> rather than the pixel data. Thus, it's clearly related to drag-and-drop vs. copy-and-paste despite the source supposedly being the same. Testing in SeaMonkey 2.19, drag-and-drop from a browser window into a mail/news composition window produces a reference, not encoded pixel data. Drag-and-drop from Firefox 21.0 produces a "data:" URI; drag-and-drop from a SeaMonkey browser window into Thunderbird 17.0.6 produces a "data:" URI as well. Thus, crossing application boundaries seems to be a factor here too. BTW: Drag-and-drop from Firefox into Thunderbird's /attachment/ pane still gives me the behavior as described in bug 557708 comment #2: An apparently temporary BMP file is created and attached, but removed already at the time of sending, thus causing an error and the send process to fail. I'm leaving this unconfirmed as it still has to be determined whether this is a MailNews issue at all or needs to go into a Core component (and if yes, which).

Ok, so it's related to MailNews Composition. I've tested with SeaMonkey 2.0.14 (which corresponds to Firefox 3.5 and Thunderbird 3.0), following results: Gecko 1.9.1 browser -> Gecko 17.0 composition: "data:image/bmp" Gecko 21.0 browser -> Gecko 1.9.1 composition: "http:" For now, let's confirm this but make it dependent on bug 557708, given that the core issue seems to be the same, just something changed more recently that caused the behavior seen for the message body as well. A solution in the other bug to use a less bulky format may turn out to be a sufficient fix for this as well.

Now *this* is a surprise! For the sake of completeness, I've also tested SeaMonkey 1.1.19 (corresponding to the Firefox/Thunderbird 2.0 branch). Drag-and-drop from its browser window into the Thunderbird 17.0.6 composition window results in a "data:image/png" URI, thus actually retaining the original PNG encoding of the image moved. So, the different behavior on the source end from the 1.8.1 to the 1.9.1 branch can probably be attributed to bug 557708, whereas the change in pasting format of "http:" to "data:" seems to be the bug here. In the end, 2 different things then. If someone with a wider range of Firefox and Thunderbird versions can hunt down the time of this regression, would be good to narrow down what's going on.

Linux isn't affected, drag-and-drop here results in an "http:" reference as expected.

wow rsx11m, thank you so much for your remarkably professional and scientific research and work! I'm also 100% sure that this bug has been introduced rather recently, I guess when someone changed the copy/ paste behavior: now: in FF Windows with only a jpg URL: Ctrl A, Ctrl C --> in TB message compose: Ctrl C: --> <img ... src="http://..> I am pretty sure that still not too long ago this would result in a inlined either original pixel or png format grfx. So for now I am happy that thanks to you I found about about that copy/ paste works. Just need to remember that, and not use drag & drop anymore. One needs to stay flexible and adapt anyway, right .. ;)?

This is a repost from a different thread. The information is relative to this issue and <A HREF="https://bugzilla.mozilla.org/show_bug.cgi?id=557708">bug 557708</A>, so I'm adding it to both these threads: Firefox 24 Steps to reproduce: drag & drop From Firefox, drag an image from a web page to a Windows Explorer window Doing so copies the selected image to the Windows Explorer folder, but ALSO creates a .BMP bitmap copy in C:\Documents and Settings\UserName\Local Settings\Temp So many of the comments below describe similar or the same behavior, dragging-dropping from Firefox to Thunderbird, however it should be helpful to know it also occurs by dragging from Firefox to Windows Explorer (and the Desktop) Shout-out of thanks to @rsx11m Until this is corrected, I've just had to make a .BATch file to DEL them

Resource name used by Tb and Text editor: View local .jpg file by SeaMonkey 2.19, drag&drop shown image. --- who used file: uri --- Drop at Firefox : file:///C:/wada/@@@/Data/JpegFile.jpg is shown Drop at Text Editor(Sakura Editor) : string of file url is generated. file:///C:/wada/@@@/Data/JpegFile.jpg --- who used data: uri --- Drop at composer of Tb 24 on Win-XP : Image Location = data:image/x-bmp;base64,Qk2iURA... Drop at new window of Notepad.exe. BMP data is pasted in edit window, with file name=emafb2dy.bmp Problem in choice of resource from resource name/type list upon drop event? > drop event handler > http://mxr.mozilla.org/comm-central/source/mozilla/toolkit/content/nsDragAndDrop.js#439 > Inadequate Flavor is used? Firefox searchs text or uri type data? First one is used by Tb?

onDrop handler of composer > http://mxr.mozilla.org/comm-central/source/mail/components/compose/content/MsgComposeCommands.js#4110 Why file;// uri is not chosen by composer, even though Firefox, Sakura Editor can choose it? When item.flavour.contentType == "text/x-moz-url", uri is checked by following code. > 4165 try { > 4166 let scheme = Services.io.extractScheme(rawData); > 4167 // don't attach mailto: urls > 4168 if (scheme == "mailto") > 4169 isValid = false; > 4170 } > 4171 catch (ex) { > 4172 isValid = false; > 4173 } Error is returned to JavaScript code from Services.io.extractScheme as exception?

(a) If Drag&Drop of jpeg image file from Windows Explorer to Tb's composer window on Win-XP", used Image location by Tb was "data: image/jpeg,base64,..." and mime-type=image/jpeg is generated in draft mail/sent mail by Tb. There is no problem in this case. (b) If Drag&Drop of shown jpeg image data at SeaMonkey to Tb's composer window on Win-XP", used Image location by Tb was "data: image/x-bmp,base64,..." and mime-type=image/x-bmpwas was generated in draft mail/sent mail by Tb. In this case, Tb 24 doesn't show image/x-bmp as "displayable mime-type", image/x-bmp part is always shown as attachment, with any View/Message Body As and View Display Attachments Inline mode. If "Content-Type: image/x-bmp" in message source is altered to "Content-Type: image/bmp" by Text Editor", Tb 24 showed the image part as "embed image in HTML". i.e. image/bmp is displayable for Tb 24, but image/x-bmp is not displayable or Tb 24. When resources are passed to Tb via Drag&Drop, Tb can use any of dataList[i][N].flavour for passed element of dataList[i]. It's all up to Tb. When Tb decided to use raw data passed from Drag starter, and when the data is BMP data, what's wrong in setting Cotent-Type: image/bmp? If actual attriute of passed raw data such as BMP is too BAD for Tb, why Tb doesn't use file URL like flavor as done by Firefox? (In reply to rsx11m from comment #8) > Gecko 1.9.1 browser -> Gecko 17.0 composition: "data:image/bmp" > Gecko 21.0 browser -> Gecko 1.9.1 composition: "http:" Drop handler of Tb checks flavor of first attrubute only. It's merely "first one=image/bmp raw data in Gecko 1.9.1" and "first one=http: data in Gecko 21.0"? > http://mxr.mozilla.org/comm-central/source/mail/components/compose/content/MsgComposeCommands.js#4121 > 4121 var item = dataList[i].first;

FYI. Following is event.dataTransfer content upon drop. "Use which data upon drop" is all up to Thunderbird. Because event.dataTransfer.types[0] (first flavour) == application/x-moz-file, Tb's drop handler chooses event.dataTransfer.files[0](first file) and directly uses data of event.dataTransfer.files[0]. Tb's drop handler doesn't look other event.dataTransfer.types[1 to N]. Because original file is .jpg file, original URI can be obtained via text/x-moz-url data, text/uri-list data etc. in Case-1. (Case-1) event.dataTransfer upon drop event by: View an image file by SeaMonkey, Drag shown image in SeaMonkey, and drop at an element. > Drop event at iD=button-newmsg, event.dataTransfer = { > [dropEffect] = move > [effectAllowed] = uninitialized > [files] = { > [0] = { > [size] = 1069474 > [type] = image/x-bmp > [name] = rx69peth.bmp > [lastModifiedDate] = Thu Apr 10 2014 09:54:54 GMT+0900 > [mozFullPath] = C:\DOCUME~1\wada\LOCALS~1\Temp\rx69peth.bmp > } > [length] = 1 > } > [types] = { > [0] = application/x-moz-file > [1] = text/html > [2] = text/x-moz-url > [3] = text/uri-list > [4] = text/x-moz-url-data > [5] = text/plain > [6] = Files > [length] = 7 > } > [mozItemCount] = 1 > [mozCursor] = auto > [mozUserCancelled] = false > [mozSourceNode] = null > } (Case-2) event.dataTransfer upon drop event by: Drag one image file(same file as Case-1) from Windows Explorer, and drop at an element. > Drop event at iD=button-newmsg, event.dataTransfer = { > [dropEffect] = none > [effectAllowed] = uninitialized > [files] = { > [0] = { > [size] = 52786 > [type] = image/jpeg > [name] = JpegFile.jpg > [lastModifiedDate] = Tue Apr 05 2011 14:58:09 GMT+0900 > [mozFullPath] = C:\wada\@@@\Data\JpegFile.jpg > } > [length] = 1 > } > [types] = { > [0] = application/x-moz-file > [1] = text/x-moz-url > [2] = Files > [length] = 3 > } > [mozItemCount] = 1 > [mozCursor] = auto > [mozUserCancelled] = false > [mozSourceNode] = null > } See following for Drag&Drop in Mozilla and dataTransfer object. > https://developer.mozilla.org/en-US/docs/DragDrop/Drag_and_Drop > https://developer.mozilla.org/en-US/docs/DragDrop/Drag_Operations#drop > https://developer.mozilla.org/en-US/docs/Web/API/DataTransfer

FYI. (Case-1-X) Data obtained by event.dataTransfer.getData( event.dataTransfer.types[N] ) in Case-1(passed from SeaMonkey). > application/x-moz-file = > text/html = <img class="decoded" alt="file:///C:/wada/@@@/Data/JpegFile.jpg" src="file:///C:/wada/@@@/Data/JpegFile.jpg"> > text/x-moz-url = file:///C:/wada/@@@/Data/JpegFile.jpg [LF] file:///C:/wada/@@@/Data/JpegFile.jpg > text/uri-list = file:///C:/wada/@@@/Data/JpegFile.jpg > text/x-moz-url-data = file:///C:/wada/@@@/Data/JpegFile.jpg > text/plain = file:///C:/wada/@@@/Data/JpegFile.jpg > Files = (Case-2-X) Data obtained by event.dataTransfer.getData( event.dataTransfer.types[N] ) in Case-2(passed from Windows Explorer). > application/x-moz-file = > text/x-moz-url = file:///C:/wada/@@@/Data/JpegFile.jpg > Files =

FYI. Bug 992633 is for "text/plain of embade image part" case. Tb uses "data:;base64,/9j...". This is because event.dataTransfer["files"][0]["type"] = null. This is a variant of "image/x-bmp from SeaMonkey" case.

In both "file:\ URL via event.dataTransfer.getData" use and event.dataTransfer["files"][0]["mozFullPath"] use, "file read of local HDD file via full path" is needed : from ordinal HDD file in one case, from temporary file on HDD in other case. If local HDD file, from perspective of file I/O, there is no difference between 'file URL' and absolute path from event.dataTransfer["files"][0]["mozFullPath"]. 'Advantage of event.dataTransfer["files"][0]["mozFullPath"] use' is in http:/https: URL case only. HTTP GET is done by Browser already. How about procedure like next? var URL = event.dataTransfer.getData("URL"); if(URL && URL is file: URL) Use it; else if(URL && URL is httpX: URL && event.dataTransfer["files"][0]["mozFullPath"]) Use the FullPath; else if(URL && URL is httpX: URL ) Use the httpX: URL; // HTTP GET is issued by Tb

Note: event.dataTransfer.getData(type) returns only "first found data for requested type). So, this is not usable if multiple files or elements are Drag&Drop'ed. For file attachements, event.dataTransfer["files"][0 to N]["mozFullPath"] should be used, because "attach files via Drag&Drop" supports multiple files.

(A) Following is even.dataTransfer object content when "shown image in IE is Dragged and Dropped at Tb. 1. First flavour(even.dataTransfer["types"][0]) == application/x-moz-file 2. # of files(event.dataTransfer["files"].length) == 1 3. event.dataTransfer.getData("text/x-moz-url]") returns URI ("2 row data separated newline" in some browser, "single row only" in other browser. This is common in SeaMonkey, Firefox, IE8 on Win. > Drop event at iD=button-newmsg, event.dataTransfer = { > [dropEffect] = copy > [effectAllowed] = uninitialized > [files] = { > [0] = { > [size] = 122702 > [type] = image/jpeg > [slice] = function slice() > [mozSlice] = function mozSlice() > [name] = sisu_0002_skypelowengaged_ja-jp[1].jpg > [lastModifiedDate] = Thu Apr 10 2014 15:33:54 GMT+0900 > [mozFullPath] = C:\Documents and Settings\wada\Local Settings\Temporary Internet Files\Content.IE5\XKWD3RNI\sisu_0002_skypelowengaged_ja-jp[1].jpg > } > [length] = 1 > } > [types] = { > [0] = application/x-moz-file > [1] = text/x-moz-url > [2] = Files > [length] = 3 > [item] = function item() > [contains] = function contains() > } > [mozItemCount] = 1 > [mozCursor] = auto > [mozUserCancelled] = false > [mozSourceNode] = null > } > > event.dataTransfer.getData() for types = { > [application/x-moz-file] = > [text/x-moz-url] = https://sc.imp.live.com/content/dam/imp/surfaces\/mail_signin/v3/images/sisu_0002_skypelowengaged_ja-jp.jpg > https://sc.imp.live.com/content/dam/imp/surfaces/mail_signin/v3/images/sisu_0002_skypelowengaged_ja-jp.jpg > [Files] = > } (B) When multiple files are Dragged to composer of Tb from Windows Exploer, Tb inserts first image file as expected. This is true even when Non-image file is passed as file[0] and jpeg file is passed as file[1]. "jpeg file passed as file[1]" is inserted in HTML mail. This functionality should be kept. Following is a solution of "image/x-bmp from SeaMonkey" and "null mime-tipe from Nautilus"(bug 992633). if( First flavour(even.dataTransfer["types"][0]) == application/x-moz-file && # of files(even.dataTransfer["files"].length) == 1 && event.dataTransfer.getData("text/x-moz-url") returns URI && ( major-type of event.dataTransfer["files"][0]["type"] != "image" || sub-type of event.dataTransfer["files"][0]["type"] != sub-type which Tb knows ) ) Use first row of event.dataTransfer.getData("text/x-moz-url") as "Image Location". Foe "BMP data with image/bmp for originally jpeg file" case(original problem of this bug). if( event.dataTransfer["files"][0]["type"] != mime-type derived from file extention in event.dataTransfer.getData("text/x-moz-url") ) Use first row of event.dataTransfer.getData("text/x-moz-url") as "Image Location".

If # of file == 1 and event.dataTransfer["files"][0]["type"] is consistent with file extention in event.dataTransfer.getData("text/x-moz-url"), Alternate text is better set from event.dataTransfer.getData("text/x-moz-url"), because yhis is original URL of the image data.

Another possible solution: If # of file == 1 && event.dataTransfer.getData("text/x-moz-url") is ile: URL, use event.dataTransfer.getData("text/x-moz-url") as "Starting Image Location", and read local file(this is file: URL) and convert to data: URL in order to get "snap shot of image data upon insert image", as done currently when even.dataTransfer["files"].length>0.