Closed
Bug 454832
Opened 16 years ago
Closed 5 years ago
Firefox3: Drag-drop does not work across two contenteditable elements
Categories
(Core :: DOM: Editor, defect, P3)
Tracking
()
RESOLVED
FIXED
mozilla73
People
(Reporter: mohan.bulusu, Assigned: masayuki)
References
(Depends on 1 open bug, Blocks 1 open bug)
Details
Attachments
(7 files)
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.0.1) Gecko/2008070208 Firefox/3.0.1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.0.1) 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:
<html>
<body>
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><br/><br/>
<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.
</div>
</body>
</html>
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.
|
Reporter | |
Comment 1•16 years ago
|
||
|
||
Updated•16 years ago
|
Severity: critical → normal
Status: UNCONFIRMED → NEW
Component: General → Editor
Depends on: 389352
Ever confirmed: true
Product: Firefox → Core
QA Contact: general → editor
Version: unspecified → Trunk
|
|
Reporter | |
Comment 2•16 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.
|
|
Reporter | |
Comment 3•16 years ago
|
||
Works around the drga-drop bug by explicitly pasting into the destination.
|
|
Reporter | |
Comment 4•16 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.
|
|
Reporter | |
Comment 5•16 years ago
|
||
|
|
Reporter | |
Comment 6•16 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 :-(
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.
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.
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•15 years ago
|
||
|
||
Comment 11•14 years ago
|
||
|
||
Comment 12•6 years ago
|
||
This issue is still present in Firefox 60:
https://jsfiddle.net/xvqtr8Ly/1/
|
||
Updated•6 years ago
|
Blocks: editor-blink-compat
Priority: -- → P3
|
Assignee | |
Comment 13•5 years ago
|
||
This bug will be fixed by bug 1597829.
|
|
Assignee | |
Comment 15•5 years ago
|
||
Fixed by bug 1597829. Please file new bugs if you find remaining problems.
Status: ASSIGNED → RESOLVED
Closed: 5 years ago
status-firefox71:
--- → wontfix
status-firefox72:
--- → wontfix
status-firefox73:
--- → fixed
status-firefox-esr68:
--- → wontfix
Resolution: --- → FIXED
|
|
Assignee | |
Updated•5 years ago
|
Target Milestone: --- → mozilla73
|
||
Updated•5 years ago
|
QA Whiteboard: [qa-73b-p2]
You need to log in
before you can comment on or make changes to this bug.
Description
•