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

RESOLVED FIXED in Firefox 45

Status

()

defect
RESOLVED FIXED
5 years ago
4 years ago

People

(Reporter: Andrew, Unassigned)

Tracking

({regression})

Trunk
mozilla45
x86
Windows 7
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox44 affected, firefox45 fixed, firefox-esr38 affected, thunderbird_esr38 affected)

Details

(Whiteboard: [regression:TB13 editor])

Attachments

(1 attachment)

Posted image Screenshot.png
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
Blocks: 499008
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: regression
Version: 31 → 13
Whiteboard: [regression:TB13]
Whiteboard: [regression:TB13] → [regression:TB13 editor]
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.
Flags: needinfo?(enndeakin)
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.
Flags: needinfo?(enndeakin)
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.
Depends on: 586587
Fixed by bug 586587
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla45
You need to log in before you can comment on or make changes to this bug.