490015 - refusing to start any more drags after a drop failure

Status: RESOLVED WORKSFORME

(Core :: DOM: Copy & Paste and Drag & Drop, defect)

Description

[Robert Kaiser]

Build identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1b5pre) Gecko/20090424 Lightning/1.0pre SeaMonkey/2.0b1pre
but I have seen the symptom for at least months intermittently without knowing how to trigger it.

When a drop fails (that's at least one way to trigger it, there might be more), SeaMonkey or Thunderbird refuse to start any more drags.

Steps to reproduce (verified on a Shredder with similar Build ID as above):
1) Try dragging a message to a different folder, notice that you get a drag cursor and drop marker (you can move the mouse back to the thread pane and effectively not move the message). We now know that things still work fine.
2) Drag a file from Dolphin (that's what I did here on KDE4, should work with something else from a different app) to the empty space in the folder pane (or any other place where you can't drop it - NOT the message pane) and see how you get a "drop not possible" mouse cursor there. Now release the mouse button like you would drop it there. We now have a failed drop.
3) Try dragging a message to a different folder again and notice that you don't get a drag cursor or drop marker, as we don't actually start a drag any more.

I kind of suspect the problem to be in core d&d code but don't know specifics, it could also be that Thunderbird and SeaMonkey both are missing some adaptations to d&d changes that were made one day.

My SeaMonkey build ends up in that end stage of refusing drags every few days, but I never knew how to trigger it, I often don't remember any failed d&d actions before I see that, so it's entirely possible that there are other ways to trigger that state, but this is one way I could reliably verify on a Shredder build.

Comment 1

[Wayne Mery (:wsmwk)]

Can someone repro in linux or Mac - SM OR TB? 

steps don't fail for me in XP in Thunderbird trunk and 20090116 SeaMonkey/2.0a3pre (sorry that's oldish I know)

Kairo, does anything turn up in debug mode?

Comment 2

[Melchert Fruitema]

For the record, I cannot reproduce this on MacOS X with Tb 2.0+. 

I have an alternate test for Tb: 
drag & drop the download for an extension (.xpi) from the AMO web page 
into the addons/extension manager's window of Tb.

Comment 3

[Wayne Mery (:wsmwk)]

thought we had something like this with TB dragging folder or message, but guess I'm thinking of bug 474000, which wouldn't be related to this?

Comment 4

[Wayne Mery (:wsmwk)]

(wonders if drag failure after Bug 458570 is triggered is related)

Comment 5

[Wayne Mery (:wsmwk)]

kairo, can you still reproduce?

Comment 6

[Robert Kaiser]

No, I can't reproduce any more. I'm seeing a different D6D failure all the time in the SeaMonkey browser, but that one is recoverable and has nothing to do with the one reported here.