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

Status: RESOLVED FIXED

(Core :: DOM: Editor, defect)

Description

[angie1984]

Attachment: 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.

Comment 1

[Loic]

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

Comment 2

[Loic]

My guess goes to this suspected bug:
Bug 499008 - Move editor over to new drag and drop api

Comment 3

[Neil Deakin]

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

[(no longer active)]

Yes, that makes sense.  Can you please write a patch which does that?  Thanks!

Comment 5

[Neil Deakin]

Attachment: patch

Comment 6

[(no longer active)]

Comment on attachment 658872 [details] [diff] [review]
patch

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

Looks good.  Can you also add a test please?

Comment 7

[Lukas Blakk [:lsblakk] use ?needinfo]

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.

Comment 8

[Neil Deakin]

Attachment: patch with test

Comment 9

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/f1628e236a1a

Comment 10

[Alex Keybl [:akeybl]]

Please nominate for uplift if you feel this fix is low risk. If not, we should untrack for release.

Comment 11

[(no longer active)]

I'd be fine with uplifting this.  What do you think, Neil?

Comment 12

[Alex Keybl [:akeybl]]

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.

Comment 13

[Lukas Blakk [:lsblakk] use ?needinfo]

Seems like there's no rush to request uplift, marking wontfix for 17 and this can ride the trains.

Comment 14

[Manuela Muntean [Away]]

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?

Comment 15

[(no longer active)]

Hmm, can you please test it on the build from comment 9?

Comment 16

[Manuela Muntean [Away]]

(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