Closed
Bug 1050566
Opened 12 years ago
Closed 10 years ago
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
Categories
(Core :: DOM: Editor, defect)
Tracking
()
RESOLVED
FIXED
mozilla45
People
(Reporter: Andrew, Unassigned)
References
Details
(Keywords: regression, Whiteboard: [regression:TB13 editor])
Attachments
(1 file)
|
132.88 KB,
image/png
|
Details |
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).
|
||
Comment 1•11 years ago
|
||
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
status-thunderbird31:
--- → affected
status-thunderbird32:
--- → affected
status-thunderbird33:
--- → affected
status-thunderbird34:
--- → affected
status-thunderbird_esr24:
--- → affected
status-thunderbird_esr31:
--- → affected
Ever confirmed: true
Keywords: regression
Version: 31 → 13
|
||
Updated•11 years ago
|
Whiteboard: [regression:TB13]
|
|
||
Updated•10 years ago
|
Whiteboard: [regression:TB13] → [regression:TB13 editor]
|
|
||
Comment 2•10 years ago
|
||
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.
|
|
||
Updated•10 years ago
|
status-thunderbird31:
affected → ---
status-thunderbird32:
affected → ---
status-thunderbird33:
affected → ---
status-thunderbird34:
affected → ---
status-thunderbird_esr24:
affected → ---
status-thunderbird_esr31:
affected → ---
Component: Message Compose Window → Editor
Product: Thunderbird → Core
Version: 13 → Trunk
|
|
||
Comment 3•10 years ago
|
||
Neil, could you take a look since it's alleged that you broke it, see comment #1.
Flags: needinfo?(enndeakin)
|
|
||
Updated•10 years ago
|
status-firefox44:
--- → affected
status-firefox-esr38:
--- → affected
status-thunderbird_esr38:
--- → affected
|
|
||
Updated•10 years ago
|
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
|
||
Comment 5•10 years ago
|
||
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.
|
|
||
Comment 6•10 years ago
|
||
(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.
|
|
||
Comment 7•10 years ago
|
||
Fixed by bug 586587
Status: NEW → RESOLVED
Closed: 10 years ago
status-firefox45:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla45
|
||
Updated•4 years ago
|
You need to log in
before you can comment on or make changes to this bug.
Description
•