This effectively was gesture fallout, the builtin DnD gesture in gtkdnd.c was triggered with buttons it didn't intend to, moving to gtk+

Created attachment 285356 [details] [review]
dnd: Make the drag gesture obey the button mask specified

This was forgotten when making DnD use a GtkGesture in the handlers
attached to the widget in gtk_drag_source_set(). The gesture must obey
the specified button mask, and switch to denied state if the pressed
button isn't part of the given mask.

Created attachment 285357 [details] [review]
treeview: Run the row dragging gesture on the bubble phase

This is so signal handlers have an opportunity to undo its effect by
returning GDK_EVENT_STOP on ::button-press-event, just like they used
to do pre-gestures.

Review of attachment 285356 [details] [review]:

sure

Review of attachment 285357 [details] [review]:

ok

Do we need the same fix in the icon view ? Thats where I noticed the problem initially...

(In reply to comment #6)
> Do we need the same fix in the icon view ? Thats where I noticed the problem
> initially...

icon view is one of the few major icons not ported yet to GtkGestures. it was failing only due to the issue in the first patch, gtk_icon_view_enable_model_drag_source() would set a 0 button mask to gtk_drag_source_set(), and then start it itself on motion_notify. The DnD code was ignoring the 0 button mask, so even if the button press emission was stopped before the icon view handler, the DnD attached handlers would still run first due to g_signal_connect() ordering.

As for the second patch, the treeview was always capturing those events, so it was calling gtk_drag_begin() even before the gtkdnd handlers did.

Clearly, everything was too eager at starting DnD...

Attachment 285356 [details] pushed as 6f53895 - dnd: Make the drag gesture obey the button mask specified
Attachment 285357 [details] pushed as bf8f824 - treeview: Run the row dragging gesture on the bubble phase