Observation: It's not possible to move (i.e. click & drag) the location of icons around on the GNOME desktop with this bug.  Any attempt to do so results in the icon "returning" (via an animation) to the original location.

Observation #2: Mail messages can't be dragged between folders in Thunderbird, e.g. (they also "return" back to the original location).

I've reproduced this bug and isolated the issue to 0efb24f589a74c4a4e78a1803d6e7205be9c1984 (http://git.gnome.org/browse/gtk+/commit/?id=0efb24f589a74c4a4e78a1803d6e7205be9c1984)

I think this should be moved from "UNCONFIRMED" state since affects to people from, at least, Ubuntu and Gentoo. Thanks

Yes please confirm it.  This is causing problems.

I fail to reproduce the problem with vncviewer and vinagre, locally.

More detailed reproduction instructions are needed.

Hi Matthias,

Thank you for having a look into this.  With vinagre, I think that you attach to the console session (running on :0) ?  If so, the fault is not apparent in this case.  Starting a gnome X session on :1, :2 etc should reproduce the issue.

Let me know if you're unable to reproduce.

Thanks,

Patrick

I did 2 clean installs of Ubuntu Maverick Meerkat under vmware.

I confirmed that controlling the "real" desktop works fine.

Installed "tightvncserver" and "vnc4server" on vmB.

Started the server with the "vncserver" command.

Connected to vmB from vmA - problem confirmed.

-Tom

Please set this Bug to confirmed, read above and get it fixed, it is really breaking a lot of functionality not being able to drag AND DROP.

(In reply to comment #9)
> Please set this Bug to confirmed,

the NEW state is generally not used by GNOME developers, and definitely not by GTK+ developers. the bug has been filed, that's usually enough. NEW bugs don't get resolved any faster than UNCONFIRMED ones.

> read above and get it fixed,

sure. pay somebody to do it.

or, better yet: patches welcome.

Or how about not breaking it in the first place ?

Patch was provided in comment 3. It just needs to be applied with -reverse.

According to SHAPE extension library document:
> If the extension is not supported, XShapeGetRectangles returns NULL. Otherwise,
> it returns a list of rectangles that describe the region specified by kind.

In fact it was even mentioned in the comment that was removed.

Could someone tell me how do I apply this patch in debian squeeze?

(In reply to comment #12)
> Could someone tell me how do I apply this patch in debian squeeze?

You convince gtk+ developers to integrate the change. I’m personally not convinced the best course of action is to revert a random commit, so I’ll wait for their decision before doing any change to a stable release.

I can confirm the bug happening on Ubuntu 11.04 using xrdp (which uses vnc) to log into the machine which is configured as an ltsp server. In fact, nothing is draggable - Desktop icons, objects in applications like Thunderbird, etc.

May I kindly ask the gtk+ developers to accept the patch provided in comment 3 ?

This makes a number of GNOME and GTK+ apps unusable over VNC, and it makes GNOME an unattractive (and in a number of cases completely unusable) option for those who remotely administer machines.

I understand that developer time is valuable and all, but this issue has been open for a year, seems highly visible, and has a candidate fix.  Does it really take years to resolve a major issue like this?

Please, guys, be kind enough to fix this. It seems like not too much work, and if the changes are not made soon, they'll never be made. Just in my office 3 people struggle daily with that, and the only solution apparently is to stop using vnc-server and use nx-server. And that's not really a solution for us.

Best regards,
Daniel

Confirmed debian/squeeze, gtk v2.20.1-2.

This bug affects more than just gnome:
* XFCE4's xfce4-panel (rightclick/select 'move' on a panel item)
* xfwm4-settings (titlebar buttons)
* XFCE and LXDE's file manager/desktop programs (thunar and pcmanfm)
* plain GTK-only apps are affected; 'gftp-gtk' for example

This is present in lxde, xfce4, and a barebones 'xterm & gftp-gtk' xsession.

This happens in tightvncserver 1.3.9-6.1+b1 (multiple vnc clients), and in Cygwin/X 1.9.2.0.

This is -definitely- caused by http://git.gnome.org/browse/gtk+/commit/?id=0efb24f589a74c4a4e78a1803d6e7205be9c1984; reversing the patch, building, exiting gtk apps, and copying over the affected libgdk-x11-2.0.so.0.2000.1 fixes it. Restoring the original libgdk-x11-2.0.so.0.2000.1 breaks it.

This is definitely present debian/squeeze 6 and ubuntu/lucid 10.04 LTS. If there is no machine available that runs either of these distros, it is trivial to reproduce by grabbing an openvz template from http://wiki.openvz.org/Download/template/precreated, and using chroot:

# mkdir /opt/debtest; cd /opt/debtest ; wget http://download.openvz.org/template/precreated/debian-6.0-x86.tar.gz ; tar xvfz debian-6.0-x86.tar.gz ; chroot .

# apt-get update ; apt-get install tightvncserver jwm icewm gftp-gtk ; vncserver



...Can this be marked confirmed already? It's been 1.5 years.



fritz_da_silva: You can fix this in squeeze as so:

# mkdir gtkfix ; cd gtkfix
# wget -O reverseme.diff 'http://git.gnome.org/browse/gtk+/patch/?id=0efb24f589a74c4a4e78a1803d6e7205be9c1984' 
# apt-get dpkg-dev
# apt-get build-dep libgtk2.0-0
# apt-get source libgtk2.0-0
# cd gtk+2.0-2.20.1
# patch -R -p1 < ../reverseme.diff
# dpkg-buildpackage
# dpkg -i ../libgtk2.0-0_2.20.1-2_i386.deb

(In reply to comment #17)

> ...Can this be marked confirmed already? It's been 1.5 years.

setting this bug as NEW won't make it magically fix itself any faster: the gtk developers don't use the NEW state in Bugzilla, as I said in comment 10.

reverting a random commit also won't be enough, given that the commit fixes a bug in two other programs.

investigation on why the commit broke tightvncserver and/or xrdp would be appreciated, given that the gtk maintainer said that he cannot reproduce with vncviewer and vino.

(In reply to comment #18)
> reverting a random commit also won't be enough, given that the commit fixes a
> bug in two other programs.
> 
> investigation on why the commit broke tightvncserver and/or xrdp would be
> appreciated, given that the gtk maintainer said that he cannot reproduce with
> vncviewer and vino.

I've already pointed out that it breaks specification. Is that not enough ?

(In reply to comment #18)
> investigation on why the commit broke tightvncserver and/or xrdp would be
> appreciated, given that the gtk maintainer said that he cannot reproduce with
> vncviewer and vino.

Also, gtk maintainer tried to reproduce it with vinagre which is not an X server, but just a screen-scraper for existing display.

He needs to use a real Xvnc server. Detailed instructions were provided in Ubuntu bug.

 
> Also, gtk maintainer tried to reproduce it with vinagre which is not an X
> server, but just a screen-scraper for existing display.
> 
> He needs to use a real Xvnc server. Detailed instructions were provided in
> Ubuntu bug.

Trying to teach me the basics is not going to make your case stronger.

vinagre is not a 'screen-scraper'. I have been using vinagre as a vnc client.
But neither with vino nor with Xvnc as vnc server have I been able to reproduce dnd-related segfaults in either gtk2 or gtk3.

So, if you want to increase the chances of this ever getting fixed, instead of snide comments, I recommend that you provide a stacktrace or even better some analysis as to how the 'offending' commit is causing the problems you are seeing. Using bisection to find the commit is valuable, but we also need to understand what the actual issue is.

*** Bug 621078 has been marked as a duplicate of this bug. ***

Why are Vino and XVnc even still being discussed when they provide VNC automation of an EXISTING, *real*, _has_a_monitor_, display; and this bug has been known forever to occur with virtual, not-real, things like both tightvncserver and vnc4server, to name 2 that fail, displays.  Vino and XVnc are *useless* for those of us affected by this, because we typically are creating vnc-controllable displays that exist ONLY for vnc-control - and don't have a 'real' X-Display.  If I was the developer that had broken it, I would have some interest in helping figure out the issue - have they been informed?  I mean, I'm just living with it, that D&D doesn't work over VNC.  Plus, the client is NOT relevant - it fails just fine with Vinagre.

This is EASY to reproduce.  It is frustrating to see the discussion going the way it is, because this is NOT rocket science to make fail.  Just instantiate a VNC server that *doesn't* control an existing display, but creates its own, such as both tightvncserver and vnc4server.  Connect to it with any client.  Drag something from folder to folder.  Voila!

 

> According to SHAPE extension library document:
> > If the extension is not supported, XShapeGetRectangles returns NULL. 

Well, if the patch breaks the specification, then the explanation should be why awn and notify-osd are wanting the broken bad illegal wrong problematic behavior, and the patch should be reversed.  Later if someone is curious why VNC requires the specification be followed, they can do that, in their free time.

> Why are Vino and XVnc even still being discussed when they provide VNC
> automation of an EXISTING, *real*, _has_a_monitor_, display; 

No, that is not what Xvnc does. But that is really besides the point, anyway. What you need to tell me is what characteristics the X server has that your gtk application is using. Does it support the shape extension, or not ?

> Well, if the patch breaks the specification, then the explanation should be why
> awn and notify-osd are wanting the broken bad illegal wrong problematic
> behavior, and the patch should be reversed.

The patch does not break any specification. The problem is that the XShape library api is a bit defective. Returning NULL from XShapeGetRectangles can mean two things: either the server does not support the shape extension, or the requested region is empty. awn and notify-osd are both well within the spec when they set an empty input shape on their windows.

Created attachment 204479 [details] [review]
a patch

Here is a patch that should fix dnd on X servers that don't support the shape extension. Let me know if it works for you. Note that the patch is against gtk3, but it should apply to 2.24 with minor adaptation.

Please try to keep the discussion a bit respectful please. We're all trying to improve GNOME. I don't want to start disabling accounts.

Created attachment 204499 [details] [review]
a patch for GTK+ 2.24.8

modified Matthias' patch for GTK+ 2.24.8.
tested on Debian gtk+2.0 2.24.8.

(In reply to comment #26)
> Created an attachment (id=204479) [details] [review]
> a patch

this fixes VNC DnD problem, thank you.
tested on Debian gtk+3.0 3.2.3-1.

thanks for testing. Pushed to 2.24, 3.0 and 3.2, as well as master.

Sorry for confusing vino with vinagre and thanks for fixing the problem.

As to the defective XShapeGetRectangles (not following spec), there was a patch submitted to xorg some time ago to fix that but unfortunately it never got committed:

http://patchwork.freedesktop.org/patch/2726/

Created attachment 205526 [details] [review]
fix vs 2.20.1

Here's a backport to 2.20.1. Not sure if 2.20 is still maintained here, but this should fix things properly for debian/squeeze users. To apply for dpkg-buildpackage, just toss it into gtk+2.0-2.20.1/debian/patches and add 
080_gdk_remote_drag-n-drop.patch
to the gtk+2.0-2.20.1/debian/patches/series