contenteditable=false nested in contenteditable=true breaks drag'n'drop

RESOLVED FIXED in Firefox 18

Status

()

Core
Editor
RESOLVED FIXED
5 years ago
5 years ago

People

(Reporter: angie1984, Assigned: Neil Deakin (away until Feb 4))

Tracking

({regression, testcase})

13 Branch
mozilla18
x86_64
Windows 7
regression, testcase
Points:
---

Firefox Tracking Flags

(firefox15- wontfix, firefox16- wontfix, firefox17+ wontfix, firefox18+ fixed)

Details

Attachments

(2 attachments, 1 obsolete attachment)

311 bytes, text/html
Details
7.82 KB, text/plain
Away for a while
: review+
Details
(Reporter)

Description

5 years ago
Created attachment 658381 [details]
test.html

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20100101 Firefox/13.0.1
Build ID: 20120614114901

Steps to reproduce:

1. open test.html (attached)
2. select the "contenteditable false" text so it is all selected (double click)
3. drag it to the beginning of the line in front of all letters.

Note:it seems to only happen if it is the first time the div is dragged and dropped. 
This did not happen in Version 11.


Actual results:

Aditionally to moving the div with contenteditable=false to the beginning of the line, it also added the text (without div tags) after the first character of the line.


Expected results:

I would expect only the contenteditable=false-div to be moved and no duplicated text to appear.

Updated

5 years ago
Attachment #658381 - Attachment mime type: text/plain → text/html

Comment 1

5 years ago
It's a regression in Firefox 13.

m-c
good=2012-02-17
bad=2012-02-18
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=2271cb92cc05&tochange=550779e6bab4

m-i
good=2012-02-17
bad=2012-02-18
http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=b3a3372fecae&tochange=c331db290cd8
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: regression, testcase

Comment 2

5 years ago
My guess goes to this suspected bug:
Bug 499008 - Move editor over to new drag and drop api
Blocks: 499008
tracking-firefox15: --- → ?
tracking-firefox16: --- → ?
tracking-firefox17: --- → ?
tracking-firefox18: --- → ?
Component: Untriaged → Editor
Product: Firefox → Core
(Assignee)

Comment 3

5 years ago
The bug here is that DoInsertHTMLWithContext inserts the html content and then returns a failure code here at http://mxr.mozilla.org/mozilla/source/editor/libeditor/html/nsHTMLDataTransfer.cpp#664

The callinf method InsertFromDataTransfer interprets this as a "insert didn't happen" so proceeds to insert the plaintext content instead. Perhaps InsertFromDataTransfer should instead just return unconditionally after DoInsertHTMLWithContext is called.

Comment 4

5 years ago
Yes, that makes sense.  Can you please write a patch which does that?  Thanks!
status-firefox15: --- → affected
status-firefox16: --- → affected
status-firefox17: --- → affected
status-firefox18: --- → affected
tracking-firefox16: ? → +
tracking-firefox17: ? → +
tracking-firefox18: ? → +
(Assignee)

Comment 5

5 years ago
Created attachment 658872 [details] [diff] [review]
patch
Assignee: nobody → enndeakin
Status: NEW → ASSIGNED

Comment 6

5 years ago
Comment on attachment 658872 [details] [diff] [review]
patch

Review of attachment 658872 [details] [diff] [review]:
-----------------------------------------------------------------

Looks good.  Can you also add a test please?
Attachment #658872 - Flags: review+
Since this was a regression in 13 we won't respin our 15 release (now 15.0.1) for this issue, but nominate for uplift and we can take it on Aurora/Beta.
status-firefox15: affected → wontfix
tracking-firefox15: ? → -
(Assignee)

Comment 8

5 years ago
Created attachment 659330 [details]
patch with test
Attachment #658872 - Attachment is obsolete: true

Updated

5 years ago
Attachment #659330 - Flags: review+
https://hg.mozilla.org/mozilla-central/rev/f1628e236a1a
Status: ASSIGNED → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla18

Updated

5 years ago
status-firefox18: affected → fixed
Please nominate for uplift if you feel this fix is low risk. If not, we should untrack for release.

Comment 11

5 years ago
I'd be fine with uplifting this.  What do you think, Neil?
Given the fact that this has been in the build since FF13 without much user pain, we're going to untrack for FF16 and limit risk. We'd approve for Aurora 17 uplift if nominated, however.
status-firefox16: affected → wontfix
tracking-firefox16: + → -
Seems like there's no rush to request uplift, marking wontfix for 17 and this can ride the trains.
status-firefox17: affected → wontfix
I get the same behaviour, both on a Nightly from 2012-08-10 and the latest beta, Firefox 18 beta 3: after draging the selected text to the beginning of the line, I get the following text as a result: between "contenteditable false" some text in some in the end. Therefore I can't mark it verified just yet.

Nightly 2012-08-10
User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:17.0) Gecko/17.0 Firefox/17.0
Build ID: 20120810030512

Firefox 18 beta 3
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:18.0) Gecko/20100101 Firefox/18.0
Build ID: 20121205060959

Any suggestions?
QA Contact: manuela.muntean

Comment 15

5 years ago
Hmm, can you please test it on the build from comment 9?
(In reply to Ehsan Akhgari [:ehsan] from comment #15)
> Hmm, can you please test it on the build from comment 9?

Thanks Ehsan for your reply. 

I've tested the build from comment 9, with User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:18.0) Gecko/18.0 Firefox/18.0, Build ID: 20120908030556.

I get the same result as in comment 14: between "contenteditable false" some text in and some in the end
You need to log in before you can comment on or make changes to this bug.