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 761954 - Tab detach no longer works
Tab detach no longer works
Status: RESOLVED FIXED
Product: gtk+
Classification: Platform
Component: Widget: GtkNotebook
3.19.x
Other Linux
: Normal normal
: ---
Assigned To: gtk-bugs
gtk-bugs
Depends on:
Blocks:
 
 
Reported: 2016-02-12 14:53 UTC by Carlos Garcia Campos
Modified: 2016-02-15 18:09 UTC
See Also:
GNOME target: 3.20
GNOME version: ---


Attachments
gdk: Add GdkDragCancelReason enum as argument to GdkDragContext::cancel (9.90 KB, patch)
2016-02-15 16:23 UTC, Carlos Garnacho
committed Details | Review
gdkdnd: Make GtkDragContext::cancel RUN_LAST (977 bytes, patch)
2016-02-15 16:23 UTC, Carlos Garnacho
committed Details | Review
x11: Stick to the first gdk_drag_drop_done() result (1.27 KB, patch)
2016-02-15 16:23 UTC, Carlos Garnacho
accepted-commit_now Details | Review
gdkdnd: Stick to the first gdk_drag_drop_done() result (1.71 KB, patch)
2016-02-15 18:09 UTC, Carlos Garnacho
committed Details | Review

Description Carlos Garcia Campos 2016-02-12 14:53:09 UTC
I guess this is a regression of recent DND changes. I've only tried with ephy, but the problem is that when a tab drag operation fails, the create-window signal is not emitted, because the drag operation didn't fail with GTK_DRAG_RESULT_NO_TARGET but it was cancelled by gdk_dnd_handle_button_event in gdkdnd-x11.c
Comment 1 Carlos Garnacho 2016-02-15 16:23:00 UTC
Created attachment 321268 [details] [review]
gdk: Add GdkDragCancelReason enum as argument to GdkDragContext::cancel

We should conform to a minimal set of reasons for the gtk side to emit
a better GtkDragResult than GTK_DRAG_RESULT_ERROR. This fixes the notebook
tab DnD feature, where we rely on GTK_DRAG_RESULT_NO_TARGET.

In the wayland side, unfortunately we can't honor either NO_TARGET nor
USER_CANCELLED, we don't know of the latter, so we could return false
positives on the former.
Comment 2 Carlos Garnacho 2016-02-15 16:23:05 UTC
Created attachment 321269 [details] [review]
gdkdnd: Make GtkDragContext::cancel RUN_LAST

The default implementation code should act as a catch-all fallback,
we let the connected handlers to run first then.
Comment 3 Carlos Garnacho 2016-02-15 16:23:11 UTC
Created attachment 321270 [details] [review]
x11: Stick to the first gdk_drag_drop_done() result

That way we can let ::cancel callers to override the visual
result of the operation (eg. when detaching notebook tabs on
NO_TARGET), despite our catch-all gdk_drag_drop_done() call
in gdk_x11_drag_context_cancel().
Comment 4 Matthias Clasen 2016-02-15 16:34:49 UTC
Review of attachment 321268 [details] [review]:

Looks good to me
Comment 5 Matthias Clasen 2016-02-15 16:35:48 UTC
Review of attachment 321269 [details] [review]:

makes  sense
Comment 6 Matthias Clasen 2016-02-15 17:25:41 UTC
Review of attachment 321270 [details] [review]:

The alternative would be to make ::cancel return a boolean with TRUE-means-handled semantics
Comment 7 Carlos Garnacho 2016-02-15 17:34:42 UTC
(In reply to Matthias Clasen from comment #6)
> Review of attachment 321270 [details] [review] [review]:
> 
> The alternative would be to make ::cancel return a boolean with
> TRUE-means-handled semantics

Hmm, maybe... but we should find some other place for calling drag_context_ungrab() than gdk_x11_drag_context_cancel() if we add a g_signal_accumulator_true_handled() accumulator.
Comment 8 Carlos Garnacho 2016-02-15 17:40:41 UTC
Attachment 321268 [details] pushed as aad3135 - gdk: Add GdkDragCancelReason enum as argument to GdkDragContext::cancel
Attachment 321269 [details] pushed as 4636552 - gdkdnd: Make GtkDragContext::cancel RUN_LAST
Comment 9 Matthias Clasen 2016-02-15 17:53:31 UTC
Review of attachment 321270 [details] [review]:

On second thought, making gdk_drag_drop_done() one-shot is perfectly reasonable. Might be worth mentioning that in the docs, though. Also: you could just do this in the frontend code, so it is same for all backends without further work
Comment 10 Carlos Garnacho 2016-02-15 18:08:49 UTC
Pushed to the common code as suggested, and with docs blurb.

The following fix has been pushed:
38d0d0a gdkdnd: Stick to the first gdk_drag_drop_done() result
Comment 11 Carlos Garnacho 2016-02-15 18:09:01 UTC
Created attachment 321283 [details] [review]
gdkdnd: Stick to the first gdk_drag_drop_done() result

That way we can let ::cancel callers to override the visual
result of the operation (eg. when detaching notebook tabs on
NO_TARGET).

Also, document gdk_drag_drop_done() so it is mentioned that
this is a one-shot call.