Gnome hang when dragging starters to docky

Thanks for your report.
Can you reproduce this bug? If so, could you describe a simple way to reproduce it?
You can also try to press Escape when stuck in dragging mode.

I ran into this once or twice, but couldnt figure out what caused it.

Simply killing/restarting nautilus usually fixes things up -- no need to restart all of X.

Yes, it's very reproducible on my system. I have gnome-do running in docky mode, and autohide is enabled. Compiz is also running of course. This seems to happen about 50% of the time in the process of dragging an icon from the applications menu into the dock to create a launcher in the dock. It might be worthy to note that when this happens, the gnome-do dock autohides itself just as this "Drag and drop not supported, invalid drag type" error window appears, even though there is nothing being moved to cover the dock that should cause it to autohide, and the icon that I'm dragging and the mouse pointer haven't even reached the vicinity of the dock. I'm guessing maybe this error appears because something causes the dock to autohide itself when it shouldn't and somehow triggers this "invalid drag type" error? I've also seen this error happen, at much lower frequency, when I drag an icon onto the desktop from the applications menu to create a launcher.

I've managed to get out of this hang by using a keyboard shortcut to open up a terminal and then "killall gnome-panel".

I'm pretty sure Do does not pop up a dialog to say invalid drag type. This must be popping up by Nautilus. If that is the case, then it makes sense that docky hides as the popup belongs to Nautilus, which overlaps the dock. Ordinarily the dock can just ignore this desktop window, but with a popup I think it now becomes a 'group' of windows and 1 in that group overlaps == autohides.

Also would explain why you get the error just dragging to the desktop.

Try to narrow this down more. Don't run Docky for awhile, see if it happens. If it does ==> not GNOME Do's fault, file with Nautilus. If it doesn't happen, run Docky but disable autohide. Does it still happen then?

     You're right about why docky hides when this error window pops up, but I just figured out what the "real" problem is and how to trigger it 100% of the time and not 50% of the time as I had stated earlier. Actually whether you want to call it 100% or 50% of the time has more to do with how you define the sequence of events you need to do, to reproduce this bug , which actually begins with an apparent bug in gnome-do when removing launchers from docky.

1. I notice that sometimes dragging a launcher off of docky and releasing it onto the desktop in order to remove it from docky, doesn't work the first time around. The icon reappears in docky, and the animation in which the icon vanishes in a "puff of smoke" doesn't happen. Sometimes I have to add and re-add different icons a few times in order to get this bug to happen, but it happens soon enough.

2. When step 1 does happen, it takes a second drag of the same launcher onto the desktop in order to removie it from docky in a "puff of smoke".

3 Regardless of whether you did step 2 or not, as long as step 1 has occurred, dragging any icon from the gnome menu (doesn't have to be the icon from step 1) causes this error window to appear.

For me, I can only return functionality with "killall gnome-panel". Running "killall nautilus" in a terminal doesn't work. This error still happens when I turn Intellihide off (I meant Intellihide all this time, and not autohide as I had incorrectly said earlier). After recovering from this error using "killall gnome-panel", after a few minutes gnome-do crashes and closes unexpectedly with the following message in the terminal, when gnome-do was run from the terminal.

The program 'Do' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadDrawable (invalid Pixmap or Window parameter)'.
  (Details: serial 12909 error_code 9 request_code 14 minor_code 0)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the --sync command line
   option to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)

So is this a gnome-do bug? Or should I file it elsewhere?

I also forgot to add that pressing escape closes the error window but still doesn't take it out of dragging mode to restore mouse functionality. I still have to killall gnome-panel. Someone new to Ubuntu probably wouldn't know where to begin especially if alt-ctrl-backspace was disabled by default, and therefore this bug effectively creates an "unstable" system in which a person would have to hard reboot the computer (which I did myself before I learned what to do) and risk losing unsaved data in order to return everything back to normal.

Confimed here. This has caused me to park my PC once or twice as well.

Confirmed here as well, on 32-bit Jaunty with all updates and GNOME Do 0.8.2

This is an annoyance and can also occur with gnome-panel alone (I am not a Gnome Do user, but just got into a 'stuck' drag situation accidentally dragging from Nautilus to the Window List or vice-versa). At least, I assume gnome-panel is part of the problem, but killing both Nautilus and it failed to release the drag. Removing and replugging the USB mouse got some limited keyboard focus back, but also didn't release the drag this time, and window manager bindings were still hosed (no Alt-Tab or workspace switching). [Hmm... not a Compiz user there either, maybe I should've given metacity a kick.]

This observed on Karmic, wherein the Xorg cursor remains stuck as the "drag and copy" cursor similar to:
http://developer.gnome.org/projects/gup/hig/draft_hig_new/images/input-drag-cursor.png
and no clicks are passed through / the icon is impossible to 'drop.'

Expected behavior would be for the 'stickiness' to not happen in the first place and for Escape to release it if it does.
Anyone know if there's a bug upstream for this?

I've had this problem in 64-bit Karmic as well. Using gnome-do allows me to reproduce this bug reliably. I don't think I've seen an upstream bug report for this. I don't know whether it's a problem with Gnome, Nautilus, Gnome-do, or Xorg, and what and if any log files would show the source of the bug. I see it as a serious issue as it hangs the desktop and renders it effectively non-functional.

hit me too.

workaround: switch to terminal (ctrl-shift-f1), log in, execute "killall gnome-panel", log out (ctrl-d), switch back to x (ctrl-shift-f7 per default)

this should be reported upstreams

I have experienced this Issue with Lucid. I'm only able to drag one item to the dock before then needing to exit Gnome-Do - otherwise dragging a second item will cause this lockup of the GNOME desktop.