212500 - In compose window, drag and drop copies, does not move

Status: RESOLVED WORKSFORME

(MailNews Core :: Composition, defect)

Description

[Peter Kirk]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624

In a compose window, dragging and dropping text inserts a copy at the
destination location as required (as long as it is in the current window, see
bug 212499), but also leaves the text in its original place. This is not the
expected behaviour (at least in Windows) of drag and drop.

See also bug 202808 comment 3 - taking this is indeed a separate issue, I am
filing a new  bug.

Reproducible: Always

Steps to Reproduce:
1. Click "reply" to any message
2. Select any word or text
3. Drag the selection to any other place in the window

Actual Results:  
The selected text is inserted at the chosen destination but not deleted from its
original location.

Expected Results:  
The selected text should be inserted at the chosen destination and then deleted
from its original location.

Comment 1

[Bjarne D Mathiesen]

As described this is WFM for me on Mac OS X with 1.5b

Now, what bug 202808 comment 3 described is that drag&drop from the message body
window to either the subject or the address is treated as copy&paste instead of
cut&paste.

I personally don't agree that drag&drop from the messge body should be treated
as cut&paste. I'm quite happy with copy&paste for the following reasons:
- I often have to copy an email-address from the message body to an address-line
- I often need to have some part of my message body be part of the subject
In both cases, having drag&drop executing a cut&paste would be against my
interests and indeed intuitive feeling for what ought to happen.

summary needs to be changed to : 
  drag&drop from message body to address or subject is copy/paste, not cut/paste
Nominating for wontfix

Comment 2

[Peter Kirk]

This bug is not about dragging and dropping between different windows (that was
bug 202808 comment 3, and I filed a new bug here because this is a different
issue). This one is about dragging and dropping within the main text window. I
wrote before that this was always reproducible. In fact it is not, but it does
happen sometimes, and I think mostly when the source and destination are some
way apart, perhaps in separate paragraphs.

Please do not change the summary as this bug is not about "drag&drop from
message body to address or subject" (which I agree does not need fixing) but
about drag and drop within the message body. And please don't dismiss a real bug
by confusing it with a wontfix issue and then calling it wontfix.

Comment 3

[Mike Cowperthwaite]

Peter Kirk, I believe I've found the key to duplicating this bug.

If you select text in the compose window and drag it direclty to another point 
in the compose window, it will be moved.

However, if you select text in the compose window, move the cursor above one of 
the fields to which it would be copied if dropped, and then move it *back* to 
the compose window and drop, the text will be copied within the compose window.

If you agree this is the problem, the summary should be updated.

Comment 4

[Peter Kirk]

Yes, from a brief test I agree that comment 3 does correctly describe the
problem I see.

Comment 5

[Mike Cowperthwaite]

Adding dependency to the (identical)  Editor:Core  bug.

Comment 6

[Mike Cowperthwaite]

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

Comment 7

[Göran A]

This one should also be taken care of before 1.5 final, imo.  It will make the
user experience and feel of the browser as whole more similar to other
applications.  

Se also https://bugzilla.mozilla.org/show_bug.cgi?id=101542

Comment 8

[Boris Zbarsky [:bzbarsky]]

This worksforme on trunk, both as originally reported and as described in comment 3.  Please reopen if you can still reproduce with a trunk build; if so, please provide detailed steps to reproduce.

Comment 9

[Boris Zbarsky [:bzbarsky]]

Mike, do you still see the problem in comment 3?

Comment 10

[Mike Cowperthwaite]

(In reply to comment #9)
> Mike, do you still see the problem in comment 3?

I do not, using TB 1.0 forward or with Moz 1.7.  Of the installed versions I 
have to quickly check with, I have to go back to Moz 1.4 to see the symptom.