User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/37.0.2062.68 Safari/537.36 Steps to reproduce: Go to any web site in the Chrome browser (I currently have Version 37.0.2062.68 beta-m (64-bit) but this appears to have been happening for quite some time) that has link text on it. Also open up a TB Composer Window in HTML mode. Now drag and drop the link from Chrome to TB. Actual results: A bunch of Chinese looking characters get inserted (See attached) Expected results: An HTML link formatted like it was on the original web site (i.e. text for a link and put the http://... in the href).
Regression window Good: http://hg.mozilla.org/mozilla-central/rev/2271cb92cc05 http://hg.mozilla.org/comm-central/rev/4f7b194ab8fa Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0a1) Gecko/20120217 Thunderbird/13.0a1 ID:20120217030028 Bad: http://hg.mozilla.org/mozilla-central/rev/561771f01881 http://hg.mozilla.org/comm-central/rev/cf3f1b5da091 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0a1) Gecko/13.0a1 Thunderbird/13.0a1 ID:20120220030032 Pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=2271cb92cc05&tochange=561771f01881 http://hg.mozilla.org/comm-central/pushloghtml?fromchange=4f7b194ab8fa&tochange=cf3f1b5da091 Suspect: Bug 499008
Status: UNCONFIRMED → NEW
Ever confirmed: true
Version: 31 → 13
You don't need Thunderbird to reproduce this. Open Firefox. Type this into the URL: data:text/html, <html contenteditable> Now drag the link from Chrome to get (undesired) effect.
Component: Message Compose Window → Editor
Product: Thunderbird → Core
Version: 13 → Trunk
Neil, could you take a look since it's alleged that you broke it, see comment #1.
Summary: Dragging and dropping an HTML link from Chrome into Thunderbird compose window results in no link but a bunch of Chinese looking characters → Dragging and dropping an HTML link from Chrome into a <contenteditable> results in no link but a garbled text looking like a bunch of Chinese characters
I think this is fixed by bug 586587.
Although looking at that patch in 586587 a bit, I don't think it's correct. The underlying issue is that Chrome seems to add data with the clipboard format name 'text/html' using a single-byte string. We interpret the 'text/html' format as a wide string. The patch in that bug changes us arbitrarily to use single-byte strings but doesn't change the form we use for putting data on the clipboard. I'll test some more and comment about that in that bug. I would presume that the code in the editor before bug 499008 just happened to prefer one of the other formats (text/x-moz-url or text/unicode) instead just due to the way it was written.
(In reply to Neil Deakin from comment #4) > I think this is fixed by bug 586587. Hmm, "is fixed" doesn't seem to be the correct tense here ;-) You mean: Will/should/may be fixed by bug 586587.
Fixed by bug 586587
You need to log in before you can comment on or make changes to this bug.