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.

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.

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.

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(

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

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...

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.

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.

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

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.

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.

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.

r=pavlov

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.

sr=tor

Checked in.

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

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.

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