460903 - drag-and-drop into textarea deletes previously selected text

Status: NEW

(Core :: DOM: Editor, defect, P5)

Description

[IU]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b2pre) Gecko/20081020 Firefox/2.0.0.11
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b2pre) Gecko/20081020 Firefox/2.0.0.11

There are still odd bugs breaking drag-and-drop of text within and between textareas.  Two bugs have been identified and are best explained with the steps to reproduce below:

For success in reproducing, please follow these steps exactly.


Reproducible: Always

Steps to Reproduce:
1. Create a new profile and log into Bugzilla
2. Launch Firefox and visit https://bugzilla.mozilla.org/enter_bug.cgi?product=Firefox&format=guided
3. NOTE: you will not be entering a bug.  This is a page selected for specific demonstration
4. Scroll down to the "Details" textarea and highlight the entire first explanatory sentence below it.  That is, all of "Expand on the Summary... about what is wrong."
5. Drag-and-drop that highlighted text to the "Details" textarea.
6. So far so good.
7. Within the "Details" textarea, highlight the word "wrong" and drag it to the "Summary" textarea
8. OBSERVATION #1: Notice that "wrong" remains in place, within the "Details" textarea
9. Within the "Summary" textarea, highlight the word "wrong" and drag-drop anywhere in the "Details" textarea -- except the location of the preexisting word "wrong".
10. BUG #1: Notice that "wrong" has suddenly disappeared from where it was at the end of the sentence, and has been replaced by the "wrong" you drag-dropped from the "Summary" textarea.
11. Highlight any of the words in the "Details" textarea and drag to the "Summary" textarea
12. BUG #2: Notice that you cannot now drop anything to the "Summary" textarea.  However, you can drag it to any of the other textarea.
13. Click within the "Summary" textarea.  Now you will be able to again drag-drop text from the "Details" textarea to the "Summary" textarea.

Comment 1

[-fullmetaljacket-]

confirmed by nightly tester @ mozillazine 

http://forums.mozillazine.org/viewtopic.php?f=23&t=913215&st=0&sk=t&sd=a&start=15

Comment 2

[Luke Iliffe (Harlequin99)]

Blocks Bug 459323? This may get it a wider audience.

Comment 3

[Elmar Ludwig]

(In reply to comment #2)
> Blocks Bug 459323? This may get it a wider audience.

Is this a regression caused by that bug?

Regarding this bug:

BUG #1 is intentional, within the same control a move operation is performed, a copy otherwise. See the code and comments at:

http://mxr.mozilla.org/mozilla-central/source/editor/libeditor/text/nsPlaintextDataTransfer.cpp#250

Normally, pressing Ctrl (Alt on MacOS) while dropping does a copy even within the same control. The handling of this modifier is broken in the current builds (don't know if we have a report on this already), but the steps described in comment #0 should perform a text move operation. So that part is INVALID.

I cannot reproduce BUG #2 here on a current nightly build on Linux.

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1b2pre) Gecko/20081021 Minefield/3.1b2pre ID:20081021020345

Comment 4

[Alice0775 White]

You do not catch the phenomenon of BUG#1 accurately. 
>8. OBSERVATION #1: Notice that "wrong" remains in place, within the "Details"
textarea

Comment 5

[Alice0775 White]

Here, Screen Capture for BUG#1
http://space.geocities.jp/alice0775/REQUEST/BUG1.avi (Size 4MB)

Comment 6

[IU]

(In reply to comment #3)
> (In reply to comment #2)
> > Blocks Bug 459323? This may get it a wider audience.
> 
> Is this a regression caused by that bug?
> 

You're right.  I've just completed testing of versions back to 2.0.0.17 and these bugs exist there too.  Updated.

> Regarding this bug:
> 
> BUG #1 is intentional, within the same control a move operation is performed, a
> copy otherwise. See the code and comments at:
> 
> http://mxr.mozilla.org/mozilla-central/source/editor/libeditor/text/nsPlaintextDataTransfer.cpp#250
> 

You've missed the issue.  The issue is not that a copy occurs; that was the "OBSERVATION" the issue is that the drag back, triggers a latent move.  Put another way:

If dragging-and-dropping TEXT_A from textarea(1) to textarea(2) is to perform a copy, fine.  But then how come dragging TEXT_A from textarea(2) back to textarea(1) causes the original TEXT_A to be replaces such that you end up with 1TEXT_A instead of 2TEXTA?  Seems like a recipe for trouble.

> (don't know if we have a report on this already), but the steps described in
> comment #0 should perform a text move operation. So that part is INVALID.
> 

What steps are you referring to?  Are you referring to the latent move that is BUG #1?

> I cannot reproduce BUG #2 here on a current nightly build on Linux.
> 

Maybe Windows only then.  However, as indicated, I can reproduce both issues with builds going back to 2.0.0.17

Comment 7

[Elmar Ludwig]

(In reply to comment #6)
> You've missed the issue.  The issue is not that a copy occurs; that was the
> "OBSERVATION" the issue is that the drag back, triggers a latent move.

Sorry, I mixed up/misread the textarea in step 9. I see what you mean now and can reproduce that here. That is indeed a bug.

> Maybe Windows only then.  However, as indicated, I can reproduce both issues
> with builds going back to 2.0.0.17

The correct steps to reproduce bug #1 seem to be a prerequisite for bug #2. If I follow the steps correctly, I can also see bug #2 here on Linux.

Comment 8

[Elmar Ludwig]

Simpler steps to reproduce:

1. type text into a textarea
2. select part of that text in the textarea
3. select text elsewhere on the page
4. drag selected text into text area

Expected behaviour:
Selected text is inserted at drop position

Actual behaviour:
If drop position is on top of (previous) selection in textarea, nothing is inserted. Otherwise, the (previous) selection is deleted and the selected text is inserted at drop position.

Comment 9

[IU]

(In reply to comment #8)
> Simpler steps to reproduce:
> 

Confirmed.

So it seems like a bug with the Selection component that is exposed via drag-and-drop.

What do you suppose is the best component to tag this against?

Comment 10

[Luke Iliffe (Harlequin99)]

Does this bug occur on other URLs apart from the one in comment #0. I can't
reproduce it on gmail. Perhaps there is something different about the text
boxes on
https://bugzilla.mozilla.org/enter_bug.cgi?product=Firefox&format=guided

Comment 11

[IU]

(In reply to comment #10)
> I can't reproduce it on gmail. Perhaps there is something different about the text boxes ...

I can reproduce on gmail and other sites as well.  Make sure you're not testing on textareas controlled by AJAX.

Comment 12

[Elmar Ludwig]

(In reply to comment #9)
> So it seems like a bug with the Selection component that is exposed via
> drag-and-drop.

I won't guess about this without looking at the code... ;-)

> What do you suppose is the best component to tag this against?

Probably [Core:Editor] or [Core:Selection], if I had to choose.

(In reply to comment #10)
> Does this bug occur on other URLs apart from the one in comment #0.

Yes, I tried it e.g. on the textarea demo page at:

http://www.mcfedries.com/CreatingAWebPage/textarea.htm

Comment 13

[IU]

Thanks, Elmar.  Tagging against Core:Editor

Comment 14

[Mike Beltzner [:beltzner, not reading bugmail]]

Is this a regression? If so, it should be nominated for blocking, I think.

Comment 15

[IU]

The bug exists way back to the 2.0.0.x series, so I'm not sure.

Comment 16

[Wayne Mery (:wsmwk)]

still fails, but has easy workaround, so => minor

Comment 17

[Jens Stutte [:jstutte]]

Bulk-downgrade of unassigned, >=3 years untouched DOM/Storage bug's priority.

If you have reason to believe this is wrong, please write a comment and ni :jstutte.