614974 - Drag & Drop of text with a contenteditable in the document ignores dataTransfer rewrites

Status: RESOLVED FIXED

(Core :: DOM: UI Events & Focus Handling, defect)

Description

[Matt Harker]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US) AppleWebKit/534.7 (KHTML, like Gecko) Chrome/7.0.517.44 Safari/534.7
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.12) Gecko/20101026 Firefox/3.6.12 ( .NET CLR 3.5.30729; .NET4.0E)

Using the HTML5 drag & drop API, rewrites the "text/plain" or "Text" data types are ignored after the dragStart event if two criteria are met:

1. there is a node in the document which is registered as contenteditable.
2: if it is just text being dragged. As far as I can tell this does not happen with images or other arbitrary node elements.

This occurs even if the contenteditable node is not involved in the drag & drop in any way shape or form. The data persists in the dragTransfer object up until the point that the dragStart event ends, and at some point before the drop event these rewrites are ignored as the data retrieved in the drop event is the original text.

Reproducible: Always

Steps to Reproduce:
Using the test harness in the URL above:

1. Highlight the text from "Drag and drop this text please".
2. Drag & drop it into the "Drop into me!" zone.
3. Examine the textarea, the debug in it should resemble the following:

Drag starting, text to drag: "Drag and drop this text please."
Drag started, text rewrote to: "{"text":"Drag and drop this text please."}"
Drop handled. Text received: "{"text":"Drag and drop this text please."}"


4. Switch on contenteditable using the switch button.
5. Repeat steps 1 & 2.
6. Examine the textarea, the debug in it should resemble the following:


Drag starting, text to drag: "Drag and drop this text please."
Drag started, text rewrote to: "{"text":"Drag and drop this text please."}"
Drop handled. Text received: "Drag and drop this text please."
Actual Results:  
The rewrites to the text/plain data type in the dataTransfer object have been ignored by the time the drop event is fired.

Expected Results:  
The rewrites to the text/plain data type in the dataTransfer object should be present in the drop event as well as the dataStart event.

This has been tested on both the Firefox 3.x version above & Firefox 4 beta 7, both with the same results.

Comment 1

[(mostly gone) XtC4UaLL [:xtc4uall]]

Seeing this too with http://hg.mozilla.org/mozilla-central/rev/4e66b4cb5e3a.

Comment 2

[Neil Deakin]

You aren't cancelling the dragstart event, so the default behaviour of copying the text is done.

Comment 3

[Matt Harker]

The dragstart event doesn't need cancelling, according to the MDC (https://developer.mozilla.org/En/DragDrop/Drag_Operations#dragstart)

If you cancel it through event.preventDefault() (Which I assume is what you mean) it cancels the entire drag. Can you elaborate on this?

Comment 4

[Neil Deakin]

OK, sorry, I was a bit confused. This is essentially bug 499008.

Comment 5

[Felipe Heidrich]

This problem is affecting the drag and drop implementation in the Orion Editor.
(https://bugs.eclipse.org/358623)

We need to provide our own data for the drag&drop operation (because we virtualize the content) and this problem is our most serious bug.

Please fix this.

Comment 6

[Kevin Dangoor]

Adding Ehsan to this bug, since it sounds like the editor component is what needs to change (per bug 499008)

Comment 7

[Mihai Sucan [:msucan]]

Attachment: test case

Test case that is more similar to the situation in Orion. (this is based on the original TC)

Comment 8

[Neil Deakin]

The patches in bug 499008 should fix this bug. Some builds are at https://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/[e-mail]-bb420b8be7bc/

Comment 9

[Mihai Sucan [:msucan]]

Neil: thank you very much for your work!

I tried the builds and I can confirm they fix the test case I have attached to this bug. I expect these builds also work with Orion. I tried the latest upstream Orion code (which has landed the workaround for this bug), and the workaround still works fine. Once the patches from bug 499008 land, we can remove the Orion workaround.

Comment 10

[Neil Deakin]

This should now be fixed.