101542 - Text should be moved, not copied, when drag dropping from one text input to the other text input

Status: RESOLVED FIXED

(Core :: DOM: Editor, defect)

Description

[tao]

2001-09-24-05-0.9.4 build.
1. open mail composer
2. enter several sentense of text
3. highlight a group of text
4. drag and drop the highlighted text to another location (in the same 
   composition window).

Result: the text is duplicated at the drop site and the original text stay intact.
expected result: the text should be moved to the drop site instead of being copied.

Comment 1

[Kathleen :Brade]

-->brade

Comment 2

[Charles Rosendahl]

I have seen this bug in the very latest builds - 2003040208 Trunk.

Two issues (two bugs?):

1.  dragging selected text does not cause a scroll to occur when a document is
larger than the viewer frame (i.e. scrollbar present, drag in direction of
scroll bar)
2.  as soon as a drag of selected text leaves the bounds of the viewer frame,
the drag transforms from a cut to a copy operation.

Comment 3

[Bernard Alleysson]

*** Bug 240091 has been marked as a duplicate of this bug. ***

Comment 4

[Mike Cowperthwaite]

It is simple to duplicate this bug.

When dragging, move the cursor somewhere such that it changes to "do not drop", 
then to wherever you want to drop it.  The text will be copied instead of moved.

Bug 212500 is the mail-composition version of this bug.  Note that this happens 
in plain-text mail composition as well as HTML, but not in TextArea.

Comment 5

[:Gavin Sharp [email: [e-mail]]]

*** Bug 240091 has been marked as a duplicate of this bug. ***

Comment 6

[:Gavin Sharp [email: [e-mail]]]

*** Bug 297151 has been marked as a duplicate of this bug. ***

Comment 7

[Prognathous]

*** Bug 229365 has been marked as a duplicate of this bug. ***

Comment 8

[Prognathous]

Attachment: Text drag and drop testcase

I'm attaching the testcase from Bug 229365 and some steps to reproduce.

When dragging text between text widgets, Mozilla chooses to copy it instead of
to move it (like IE6 does).

This bug is divided into two issues:

1. Although Mozilla performs a Copy, the cursor has the shape of a move-object,

not a copy-object.
2. Pressing Shift to force a Move, has no effect. The text still remains in the

source widget.


Reproducible: Always

Steps to Reproduce:
1. Open https://bugzilla.mozilla.org/attachment.cgi?id=137937
2. Drag the text from one textarea to the other

Actual Results:  
The text is copied rather than moved. Unlike what Windows users would expect,
and unlike what the move-object cursor hints.

Expected Results:  
The text should move to the other textarea.

What should be fixed:

1. Drag and drop within the same instance should move the text.

If the default stays Copy, then:

1. The cursor should look like a copy-object one (with a '+')
2. Holding Shift pressed should force a Move operation.

Prog.

Comment 9

[José Jeria]

*** Bug 301691 has been marked as a duplicate of this bug. ***

Comment 10

[Prognathous]

Tweaking the summary to make this bug easier to find.

Prog.

Comment 11

[Dave Townsend [:mossop]]

*** Bug 307950 has been marked as a duplicate of this bug. ***

Comment 12

[Göran A]

I first saw this bug in Firefox 1.01. Would be really nice if this was fixed
before 1.5 final. Here's hoping :) 

Comment 13

[Sachin]

There is more to this behaviour, have a look at Bug 297153.

Comment 14

[Göran A]

I really think that this should be fixed before 1.5 final. This is such an
annoying bug and it's also dated back as early as 2001-10-12.  

Are you still on this, brade?  

Comment 15

[Martijn Wargers (dead)]

Attachment: patchv1

Well, this seems to work.
But with this fix, I get even more annoyed by bug 280635.

Comment 16

[Martijn Wargers (dead)]

I think it only works for text controls, I haven't tested it on editor/designMode iframes yet.

Comment 17

[Martijn Wargers (dead)]

Attachment: patchv2

Fixes an error in patchv1 and some comment changes.

-      // Dragging from another window onto a selection
-      // XXX Decision made to NOT do this,
-      //     note that 4.x does replace if dropped on
-      //deleteSelection = PR_TRUE;
I removed these, because they are not true, I can drop just fine from another application.

This patch doesn't work for editor/designMode iframes, another patch for that is needed.

Comment 18

[Martijn Wargers (dead)]

Comment on attachment 206661 [details] [diff] [review]
patchv2

The patch needs some improvements, but first I'm trying to fix bug 280635.

Comment 19

[Göran A]

This bug sounds to be about the same issue (Copy instead of Move)

https://bugzilla.mozilla.org/show_bug.cgi?id=212500

It's great to see progress on this, thanks.

Comment 20

[frankforest]

Still seeing this in 1.5.0.1  It affects me probably 20x per day, with the apps I use.

IE doesn't have this problem, and this seems like a meaningful disparity. (This comment isn't meant to be discouraging, but instead it's from a passionate Firefox fan!)

Comment 21

[Stuart Parmenter]

worksforme per the original bug on the trunk.

Comment 22

[Martijn Wargers (dead)]

This is still not working on the latest trunk build. I know, the bug was modified a bit, it is now about the case when dragging dropping from one text input to the other text input.
Updating the summary.

Comment 23

[Federico B P]

This Bug is also present in the OS X version (Firefox 2.0 RC3) Change the OS from Win2000 to all.

Comment 24

[Nochum Sossonko [:Natch]]

blocking-1.9.3? for the lack of wanted-1.9.3?

Comment 25

[Kathleen :Brade]

Why was this bug reassigned to nobody?
Please don't remove bugs from my list without asking.  Thank you!

Comment 26

[Nochum Sossonko [:Natch]]

(In reply to comment #25)
I'm sorry, that was me. Completely unintentional.

Comment 27

[baffclan]

WFM with newest nightly.

Application Basics:
Name: Firefox
Version: 76.0a1
Build ID: 20200325213906
Update Channel: nightly
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:76.0) Gecko/20100101 Firefox/76.0

Comment 28

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Fixed by bug 1597829.