Firefox3: Drag-drop does not work across two contenteditable elements




9 years ago
6 years ago


(Reporter: mohan.bulusu, Unassigned)


(Depends on: 1 bug)

Windows Vista

Firefox Tracking Flags

(Not tracked)



(7 attachments)



9 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv: Gecko/2008070208 Firefox/3.0.1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv: Gecko/2008070208 Firefox/3.0.1

This is probably related to  Bug 389352.

If I have two DIV elements D1 and D2 in a document, both with 
contentEditable="true", and I try to drag some text from D1 to D2, 
then the text gets removed from D1 (as expected) but does not get 
inserted into D2.

Drag-drop does work as expected within any one contenteditable element.

Reproducible: Always

Steps to Reproduce:
1. Create an html file with the following content:

Below are two DIVs, each marked with contenteditable="true". <br/><br/>
<div id="d1" style="border:red solid 1px;" contenteditable="true">
Select and drag some text from this DIV<br/>
and drop into the DIV below
<div id="d2" style="border:red solid 1px;" contenteditable="true">
You'd see that the text does not get inserted into this DIV,<br/>
even though it gets removed from the DIV above.

2. Follow the intructions in the page!

Actual Results:  
The text gets removed from the source but does not get inserted into the destination, causing a loss of data.

Expected Results:  
The text gets inserted into the second DIV.

1. The event ondragdrop does fire, when the dropping on the second DIV.
2. Drag-drop works fine within either of the DIVs.

Comment 1

9 years ago
Created attachment 338141 [details]
Test file to reproduce the bug


9 years ago
Blocks: 454843


9 years ago
No longer blocks: 454843
Severity: critical → normal
Component: General → Editor
Depends on: 389352
Ever confirmed: true
Product: Firefox → Core
QA Contact: general → editor
Version: unspecified → Trunk

Comment 2

9 years ago
I have managed to craft a workaround for this. The idea is to 
a) handle the DRAG event to grab a copy of the selection being dragged, and
b) handle the DRAGDROP event to explicitly paste the above copy into the drop point (determined using event.rangeParent and event.rangeOffset).

I am attaching the file cebugfix.htm to demonstrate this workaround.

I am still hoping that the underlying bug egts fixed in Firefox soon, so that I don't have to use this workaround.

Comment 3

9 years ago
Created attachment 338908 [details]
Test case that shows a possible workaround

Works around the drga-drop bug by explicitly pasting into the destination.

Comment 4

9 years ago
I just discovered a 2-line workaround for this bug though I have nothing but some wild guesses on why it fixes the issue!

The workaround is to add these two lines in the body's onload handler:

document.body.contentEditable = "true";
document.body.contentEditable = "inherit";

That's it! It seems that momentarily setting the contentEdiatble to true on the BODY is all it takes to enable drga-drop across multiple editable zones within it. I would be curious to hear from the Mozilla devs why this workaround works, and what the underlying issue is.

Comment 5

9 years ago
Created attachment 343136 [details]
Workaround (toggle the value of body.contentEditable)

Comment 6

9 years ago
I take that back. The "fix" doesn't work. Setting body.contentEditable back to "inherit" does not have the expected effect. It still leaves the body content as editable. Oh well :-(

Comment 7

9 years ago
Created attachment 382867 [details]
workaround update

The 1st workaround worked when copying and pasting between the different divs, but when you'd copy and paste in the same div, it would duplicate the paste.

The workaround I uploaded will check if the source div is the same as the destination div, and if they are the same, not paste it so it doesn't duplicate.

I'm fairly new to all this DOM stuff though, so it's not perfect. I can see an issue if there are multiple nested divs, since this just compares the first parent divs it can find.

Comment 8

9 years ago
Created attachment 382871 [details]
another workaround update

heh, here's another workaround to the workaround, using evt.stopPropagation(). It seems to fix it as well. This is probably a better workaround, sorry for the first attachment.

Comment 9

9 years ago
I found a focus patch but it cause an another bug : the text blink cursor disappear...
I hope, it will help to find a solution to the bug

Comment 10

9 years ago
Created attachment 392366 [details]
javascript focus patch

Comment 11

7 years ago
Created attachment 470822 [details]
Firefox 3.5 removed the dragdrop event, and replaced it with the drag event.  This workaround WORKS!
You need to log in before you can comment on or make changes to this bug.