Closed Bug 490015 Opened 16 years ago Closed 11 years ago

refusing to start any more drags after a drop failure

Categories

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

1.9.1 Branch
x86
Linux
defect
Not set
normal

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: kairo, Unassigned)

References

(Depends on 1 open bug)

Details

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.
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?
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.
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?
(wonders if drag failure after Bug 458570 is triggered is related)
Depends on: 458570
kairo, can you still reproduce?
Flags: needinfo?(kairo)
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.
Status: NEW → RESOLVED
Closed: 11 years ago
Flags: needinfo?(kairo)
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.