89438 - can't drag and drop messages from inbox to folder

Status: VERIFIED FIXED

(SeaMonkey :: MailNews: Message Display, defect)

Description

[Christopher Blizzard (:blizzard)]

Build is from the tip, Jul 05, 2001.

If I try to drag a message to a folder on the same server the message isn't
moved.  There drag looks like it succeeds because the icon isn't sent back to
the source to indicate that the drop wasn't valid.

There is no UI update indicating a move was attempted.  There are no JS errors.

Comment 1

[Asa Dotzler [:asa]]

I can confirm this problem on 070506 mozilla linux build on RH6.1 

Worksforme with 061504 mozilla win32 build on win2K, winXP and win98 and with
061508 mozilla mac build on OS 8.5 and 9.1.  

 

Comment 2

[Mike Gratton]

Not sure if it's related, but the drag cursor displayed is the copy cursor,
rather than the move cursor. I think this has changed from previous versions
where the default drag action was to move the dragges message.

I'm seeing this on Debian/Linux 070409.

Comment 3

[Mike Gratton]

Ahh, okay, I lied, the drag cursor changes to copy over a mailbox, but it still
just moves the message, when tested on Debian/Linux 062609.

Sorry for the spam. 8(

Comment 4

[(not reading, please use [e-mail] instead)]

over to naving, who has made some dnd change recently, to investigate.

Comment 5

[Navin Gupta]

Drag and drop worksfine on win and mac latest builds. I suspect that the 
problem is in gtk widget code if it is not working on linux. However, i will 
investigate...

Comment 6

[Christopher Blizzard (:blizzard)]

Well, I haven't changed anything in the linux code so if it is a problem there
then it's been exposed by something new.

Comment 7

[Navin Gupta]

D&D of messages on linux is broken. The linux widget code is not setting the 
dragAction in the dragSession code correctly. Recently to make the Options 
key work on mac, I changed code to not check explicitly check for keys in 
mailnews code but to rely on dragSession. 

blizzard, I think this will be your bug. 

Comment 8

[Navin Gupta]

More info, the dragAction is always NONE , no matter what you do COPY/MOVE

Comment 9

[Christopher Blizzard (:blizzard)]

I spent some time looking at this.  I can fix this but it's going to require an
architectural change.

Right now when we start our drag with a message we start it by saying that we
can support either a MOVE or a COPY.  So I add those to the action masks when we
start a drag.  When the dragdrop code gets a drag motion event and someone sets
canDrop, I need to notify the drag source ( in this case mozilla ) about what
kinds of actions can take place.  However, the only information that I have is
that some kind of drag is OK, but not what kind.  I need to say that it has to
be a LINK, COPY, or MOVE or what combination of that list is OK.  Right now I'm
just lying and saying that it's always COPY.  This is also true as part of the
getData() call.  It needs a mime type and an action type.

Other platforms probably have some kind of key combination or something to tell
what kind of drag is happening and set the drag type appropriately.  However, on
linux, there is not such automatic key combination.  The target ( mozilla in
this case ) needs to make a choice about what kind of request to make to get the
right data.  Our interfaces have no way of relaying that to the drag service.

Comment 10

[Navin Gupta]

I can change it to do MOVE by default in mailnews (messengerdnd.js) code,
but somehow you will have to detect a COPY correctly in the widget code. 
I am wondering how does the native drag and drop code on the other platforms 
(win32 & mac) relay the dragAction back to the DragService. 

Comment 11

[Christopher Blizzard (:blizzard)]

Attachment: patch

Comment 12

[Christopher Blizzard (:blizzard)]

I'm sitting here with a brown paper bag over my head.

It turns out that you don't need any of that information to be able to get the
data.  It also turns out that Gtk does provide the proper key semantics for
move/copy/link.  I figured this out when I started looking at the values coming
out of the drag target's list of valid actions.

Anyway, this patch updates the drag action in the drag session based on the
information in the gdk drag action information.  It also properly updates the
drag cursor icon based on whether it's a valid drop zone and what action we
should be taking. ( bug #52764 )  It also will only offer the actions that are
listed in |InvokeDragSession|.

Looking for reviews so I can get this in and fix the regression.

Comment 13

[Stuart Parmenter]

r=pavlov

Comment 14

[Scott Davis]

This seems to be a problem with nightly build 2001070810 and also the one from
July 1 or 2. Both on Solaris/SPARC. It worked on nightly builds I used in June.

Comment 15

[tor]

sr=tor

Comment 16

[Christopher Blizzard (:blizzard)]

Checked in.

Comment 17

[Sheela Ravindran]

Blizzard, 

Has this been only checked in for trunk? Should this be checked in for branch 
too?   
This is working in 2001071108 trunk build on linux.  I will leave the bug in the 
resolved state for now and will verify this based on your comments for the 
above.Thanks

Comment 18

[Christopher Blizzard (:blizzard)]

This has only been checked into the trunk.  I don't think that it needs to go
onto the branch unless something got changed there.  You should test it to make
sure.

Comment 19

[Sheela Ravindran]

verified using build:  2001-08-02-08 on linux