if (orientation) doesn't make a lot of sense but C doesn't complain and
instead evaluates orientation to TRUE for GTK_ORIENTATION_VERTICAL
(since that's 1), thus inverting the value sizes.
commit c3dc0d80f1 fixed the behavior of
GtkContainer widgets requesting an IMMEDIATE resize-mode.
However, GtkWindow has been stomping on resize-mode during realize()
since commit addcc64b9c. The combination
of factors that led to this not being a visible problem during all this
while is uncertain, but this now causes the Shell to continuously try to
relayout its ShellEmbeddedWindow (a GtkWindow subclass).
This commit separates the resize-mode as set internally by GtkWindow
from the one set with the external API, so that GtkWindow only changes
it when it had not been set before by the subclass.
https://bugzilla.gnome.org/show_bug.cgi?id=763650
The implicit grab may be finished so the pointer lies on top of the other
scrollbar, in this case one scrollbar should lose the hovering state, and
the other should gain it. So we must check for proximity in both indicators.
Besides the ::drag-failed handling in order to trigger the window creation
hook, add some handling of the application/x-rootwindow-drop mimetype, so
the same effect is achieved if the tab could be dropped in a destination
accepting this mimetype.
https://bugzilla.gnome.org/show_bug.cgi?id=763387
This makes toplevels pseudo-transparent wrt this mimetype, so if
the drag source offers this mimetype and not another that was
managed by the destination-side widget hierarchy, the window will
be an acceptable target for this mimetype, allowing it to trigger
whatever is meant to in the source side.
https://bugzilla.gnome.org/show_bug.cgi?id=763387
Don't make the popup follow the slider while it is open; that
makes interaction with it unnecessarily hard. Also move all the
popups inwards a little bit, so they are not flush with the
scales, which looks untidy.
https://bugzilla.gnome.org/show_bug.cgi?id=763380
We were not taking the scrollable borders into account when
requesting size for the scrolled window, which could lead
to underallocating the scrollbars at size allocation time
when we *did* take the borders into account.
This is most notable with treeviews, where we have the
headers as borders, and was causing the treeview-crash-too-wide
reftest to fail.
The tree walk holds a tree iter, which will become invalid
when we either remove the row that it points to or remove
all rows.
Reset the tree walk in those cases to avoid a crash that
was pointed out by Bastien Nocera.
