I can confirm this bug. 

I too can confirm this.

The reason it is a pain in the neck is that Super+click is the only combination that isn't needed by other apps I use all day long.  ctrl+click is pretty universally used for selecting multiple items in applications, and alt+click is needed by Eclipse Mylyn.

So my workaround: every time I log in, I open System->Preferences->Windows (okay, I put a shortcut on the panel so I don't have to dig into the menus) and set my movement key to alt, move my panels where I want them (they don't stick where I want 'em because of issues with multihead / nVidia's twinview), then set it back to super and close the "Windows" control.  Clunky ;-(

I've commented out the following lines in panel-toplevel.c (line 3239-3254 in version 2.26.0)

	/* Get the mouse-button modifier from metacity so that only intentional
	 * moves are considered. We don't this for non-expanded panels since we
	 * only have the handles that the user can grab. */
	if ((toplevel->priv->expand || toplevel->priv->attached) &&
	    (event->state & gtk_accelerator_get_default_mod_mask ()) != panel_bindings_get_mouse_button_modifier_keymask ())
		return FALSE;

This disables the requirement for having to press the 'moving key'. I think the cause of the bug also lies in these few lines code, but I can't quite figure it out at this time.

Hi,

Is anyone looking at this?? I realize that may not be the most critical problem, but it's still very annoying.
I didn't want to disable modifier key so I tried to have a look at the code. I found out that the following code:

	if (toplevel->priv->expand)
		g_message("expand is true");
	if (toplevel->priv->attached)
		g_message("attached is true");


	g_message("event-state: %d", event->state);
	g_message("gtk_accelerator_get_default_mod_mask: %d", gtk_accelerator_get_default_mod_mask());
	g_message("panel_bindings_get_mouse_button_modifier_keymask: %d", panel_bindings_get_mouse_button_modifier_keymask ());

	/* Get the mouse-button modifier from metacity so that only intentional
	 * moves are considered. We don't this for non-expanded panels since we
	 * only have the handles that the user can grab.*/
	if ((toplevel->priv->expand || toplevel->priv->attached) &&
	    (event->state & gtk_accelerator_get_default_mod_mask ()) != panel_bindings_get_mouse_button_modifier_keymask ()) 
		return FALSE;


results in this for Super:
** Message: expand is true
** Message: event-state: 80
** Message: gtk_accelerator_get_default_mod_mask: 469762061
** Message: panel_bindings_get_mouse_button_modifier_keymask: 67108864

and this for Alt:
** Message: expand is true
** Message: event-state: 24
** Message: gtk_accelerator_get_default_mod_mask: 469762061
** Message: panel_bindings_get_mouse_button_modifier_keymask: 8


So my conclusions are that gtk_accelerator_get_default_mod_mask () always returns 469762061 (0001 1100 000 000 000 000 000 1101) and that Super key is equal to event-state 80 (0101 0000). A logical AND between them is of course 0 and the function will return false => no movement.
Does any one know why event state is 80 and if that could be incorrect? Is there any conversion between X keys and gdk?

I wonder if this one will ever be fixed...

This issue was fixed after upgrading to Ubuntu 9.10 with gnome 2.28

It still doesn't work for <super> on my Ubuntu 9.10 installation with Gnome 2.28.1. It does works fine however with <Ctrl> and <Alt>, but it worked that way as well in the original bug report.

That's strange. I thought that when I installed 9.10 all the gnome files where replaced with new ones. But maybe I kept my modified gnome-panel.

I'm on 2.28.2 and still have this problem.

Is this happening with both compiz and metacity? Or just one of them?

It is happening with both Compiz and Metacity here.

(In reply to comment #11)
> It is happening with both Compiz and Metacity here.

Same for me.

Any news on that one?

There's a patch in bug 624572.

*** This bug has been marked as a duplicate of bug 624572 ***