After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 749737 - DnD breaks button-released events. (Setting a widget as DnD source causes button_released events to have 0 x/y coordinates)
DnD breaks button-released events. (Setting a widget as DnD source causes but...
Status: RESOLVED FIXED
Product: gtk+
Classification: Platform
Component: .General
3.16.x
Other Linux
: Normal normal
: ---
Assigned To: gtk-bugs
gtk-bugs
Depends on:
Blocks:
 
 
Reported: 2015-05-22 16:11 UTC by Leo Ufimtsev
Modified: 2015-11-11 10:07 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
small snippet to reproduce the issue. (10.00 KB, application/x-tar)
2015-05-22 16:11 UTC, Leo Ufimtsev
  Details
dnd: Remove emission of fake button release event (2.21 KB, patch)
2015-05-27 12:44 UTC, Carlos Garnacho
none Details | Review

Description Leo Ufimtsev 2015-05-22 16:11:02 UTC
If I take a widget and register it as a DnD source and connect it to a button_released event, 

Then if I start a drag operation on the button and release it, then when the button_released event is triggered, the x/y coordinates are 0.

Steps to reproduce:
 - run test app:
   make && ./main 
 - click & release the only button. You will see that x/y coords are correct.
 - now click & hold, move mouse a little bit to trigger a drag.
   now release the button. You will observe that the mouse-up event was 
   triggered but the x/y coordinates are shown as 0.

However, mouse_release event within the same gtk application should have x/y coordinates relative to the root window.


Tested on Gtk3.16.3 on Fedora 22. 
But also believed to occur on Gtk2.
------------------------------
Side note: 

SWT/Eclipse is affected by this, related bug:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=458820
Comment 1 Leo Ufimtsev 2015-05-22 16:11:35 UTC
Created attachment 303830 [details]
small snippet to reproduce the issue.
Comment 2 Leo Ufimtsev 2015-05-22 16:15:55 UTC
As a note, if the widget is not registered as drag-source, then the issue does not occur.
Comment 3 Carlos Garnacho 2015-05-27 12:43:51 UTC
I was wondering why do we receive a button release event at all, as soon as DnD is triggered, a grab is taken on an invisible window, the drag source widget should just receive GdkEventGrabBroken, and no further mouse events as long as the grab holds.

I found out we are faking a button release event when the DnD operation finishes, this seems like really old code, and actually is inconsistent with how things are done currently.

I'm attaching a patch to remove this event emission, might not be the fix that you expected though...
Comment 4 Carlos Garnacho 2015-05-27 12:44:58 UTC
Created attachment 304066 [details] [review]
dnd: Remove emission of fake button release event

Nowadays (and for quite some years now) we rely on GdkEventGrabBroken
events to be received. This fake button event seems a remnant of
the early Gtk 2.x days, and is currently even inconsistent with our
event delivery model, so just remove it.
Comment 5 Carlos Garnacho 2015-06-02 15:29:26 UTC
Attachment 304066 [details] pushed as a0e8056 - dnd: Remove emission of fake button release event
Comment 6 Leo Ufimtsev 2015-06-03 17:23:48 UTC
(In reply to Carlos Garnacho from comment #5)
> Attachment 304066 [details] pushed as a0e8056 - dnd: Remove emission of fake
> button release event

thanks for looking into this.
Comment 7 Milan Crha 2015-11-11 10:07:11 UTC
This change breaks evolution's (libgnomecanvas') handling of grabbed events, respectively of the drag end recognition, as noted in bug #755730 comment #8.