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

RESOLVED FIXED

Status

()

Core
Event Handling
RESOLVED FIXED
7 years ago
4 years ago

People

(Reporter: Matt Harker, Unassigned)

Tracking

({testcase})

Trunk
testcase
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment)

(Reporter)

Description

7 years ago
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.
Seeing this too with http://hg.mozilla.org/mozilla-central/rev/4e66b4cb5e3a.
Component: General → Event Handling
Keywords: testcase
Product: Firefox → Core
QA Contact: general → events
Version: unspecified → Trunk
You aren't cancelling the dragstart event, so the default behaviour of copying the text is done.
(Reporter)

Comment 3

7 years ago
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?
OK, sorry, I was a bit confused. This is essentially bug 499008.
Depends on: 499008

Comment 5

6 years ago
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

6 years ago
Adding Ehsan to this bug, since it sounds like the editor component is what needs to change (per bug 499008)
Created attachment 576182 [details]
test case

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

Updated

6 years ago
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows 7 → All
Hardware: x86 → All
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/
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.
This should now be fixed.
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.