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.
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
My guess goes to this suspected bug: Bug 499008 - Move editor over to new drag and drop api
tracking-firefox15: --- → ?
tracking-firefox16: --- → ?
tracking-firefox17: --- → ?
tracking-firefox18: --- → ?
Component: Untriaged → Editor
Product: Firefox → Core
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.
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: ? → +
Created attachment 658872 [details] [diff] [review] patch
Assignee: nobody → enndeakin
Status: NEW → ASSIGNED
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: ? → -
Created attachment 659330 [details] patch with test
Attachment #658872 - Attachment is obsolete: true
Status: ASSIGNED → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla18
Please nominate for uplift if you feel this fix is low risk. If not, we should untrack for release.
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
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.