refusing to start any more drags after a drop failure

RESOLVED WORKSFORME

Status

()

Core
Drag and Drop
RESOLVED WORKSFORME
9 years ago
4 years ago

People

(Reporter: Robert Kaiser, Unassigned)

Tracking

(Depends on: 1 bug)

1.9.1 Branch
x86
Linux
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

9 years ago
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

9 years ago
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

9 years ago
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

9 years ago
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

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

Updated

7 years ago
Depends on: 458570

Updated

5 years ago
See Also: → bug 239951

Comment 5

4 years ago
kairo, can you still reproduce?
Flags: needinfo?(kairo)
(Reporter)

Comment 6

4 years ago
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
Last Resolved: 4 years ago
Flags: needinfo?(kairo)
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.