Last Comment Bug 614974 - Drag & Drop of text with a contenteditable in the document ignores dataTransfer rewrites
: Drag & Drop of text with a contenteditable in the document ignores dataTransf...
Status: RESOLVED FIXED
: testcase
Product: Core
Classification: Components
Component: Event Handling (show other bugs)
: Trunk
: All All
: -- normal (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
Mentors:
http://www.theflux.co.uk/dragdropce.html
Depends on: 499008
Blocks:
  Show dependency treegraph
 
Reported: 2010-11-26 09:34 PST by Matt Harker
Modified: 2013-11-12 00:57 PST (History)
9 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
test case (3.54 KB, text/html)
2011-11-22 09:11 PST, Mihai Sucan [:msucan]
no flags Details

Description Matt Harker 2010-11-26 09:34:06 PST
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] 2010-11-26 13:21:25 PST
Seeing this too with http://hg.mozilla.org/mozilla-central/rev/4e66b4cb5e3a.
Comment 2 Neil Deakin 2011-02-08 10:57:37 PST
You aren't cancelling the dragstart event, so the default behaviour of copying the text is done.
Comment 3 Matt Harker 2011-02-08 11:04:29 PST
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 2011-02-22 07:03:46 PST
OK, sorry, I was a bit confused. This is essentially bug 499008.
Comment 5 Felipe Heidrich 2011-11-09 12:12:48 PST
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 2011-11-14 11:29:09 PST
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] 2011-11-22 09:11:33 PST
Created attachment 576182 [details]
test case

Test case that is more similar to the situation in Orion. (this is based on the original TC)
Comment 8 Neil Deakin 2011-12-02 18:05:05 PST
The patches in bug 499008 should fix this bug. Some builds are at https://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/neil@mozilla.com-bb420b8be7bc/
Comment 9 Mihai Sucan [:msucan] 2011-12-03 05:55:57 PST
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 2012-03-05 06:38:31 PST
This should now be fixed.

Note You need to log in before you can comment on or make changes to this bug.