GNOME Bugzilla – Bug 749893
Crash when trying to drag a tab from a populated GtkNotebook into an unpopulated GtkNotebook in the same group
Last modified: 2015-05-26 17:02:54 UTC
GTK is bombing in 3.16.3 when I try to drag a notebook tab from a populated GtkNotebook into an unpopulated GtkNotebook in the same group. Previous versions, e.g 3.14.5 work fine for this use case. In affected versions, as soon as any tab is dragged into the screen area occupied by an empty target notebook, I get: ----------------------8<----------------------- ** Gtk:ERROR:/build/buildd/gtk+3.0-3.16.3/./gtk/gtknotebook.c:3832:gtk_notebook_drag_motion: assertion failed: (priv->cur_page != NULL) Aborted (core dumped) ---------------------->8----------------------- Drags into populated notebooks are unaffected. In earlier unaffected versions, the tab is correctly inserted into an empty target notebook as its first page, and the program does not crash. * Demo code for this error, with notes: https://gist.github.com/achadwick/1b3505beb47d65fedfd6 * Related Mypaint bug with some stack traces: https://github.com/mypaint/mypaint/issues/322 It's breaking our tabbed workspace layout quite badly. * mclasen on IRC has identified https://git.gnome.org/browse/gtk+/commit/?id=d65ccf96ee43e3cd62a705074d452f9f87912ee2 as a potential culprit commit. This is affecting Linux and Windows alike (see MyPaint issue 322), and seems independent of desktop environment in Linux (or at least it's happening in GNOME and Xfce4 alike).
The first step is to try and revert the offending commit. The assertion protects a dereference of cur_page, but that happens only inside a conditional branch; it may make sense to move the assertion inside the same branch. You're dragging a notebook page inside an empty GtkNotebook, so it'd make sense that the current page is unset; the important thing is to verify if the code is actually doing the correct thing in that case, or if it's just exploiting undefined behaviour.
I think it is right to assume on all dest-side DnD calls that there might not be a selected page (mainly meaning it is empty), it is more of a requirement on the drag source side, because you must be dragging something :).
Created attachment 304015 [details] [review] notebook: Fix assert in ::drag-motion The drag destination might be empty, we shouldn't be checking whether it contains pages at all. Instead, check the source notebook, which ought to have a selected page if you're dragging something from there.
Review of attachment 304015 [details] [review]: Yep, this looks good to me.
Attachment 304015 [details] pushed as 3e60650 - notebook: Fix assert in ::drag-motion
Any chance this could be pushed to 3.16 as well, given that it's a crasher?
I can confirm that patching with attachment 304015 [details] [review] above fixes the issue for the 3.16 series, for the test python-gi code above anyway.
Sure, done.