GNOME Bugzilla – Bug 764605
Keyboard shortcuts are not working while drag-and-drop is active
Last modified: 2016-06-16 17:06:20 UTC
Switching applications during drag-and-drop is no longer working since upgrading to Gtk+ 3.20.2 and Gnome-3.20. This was working in Gnome 3.18 and Gtk+ 3.18.x. When dragging a palette color in Gimp using Gtk+ 2.x I can use keyboard shortcuts to switch applications. I am not sure if this is an Gtk+ issue, but this seems to be the common denominator.
x11 or wayland ?
x11. In a/gdk/x11/gdkdnd-x11.c: * All keyboard events are swallowed in gdk_dnd_handle_key_event, even those, that are not in grab_keys[]. * gdk_dnd_handle_key_event is called in gdk_x11_drag_context_handle_event and only if the seat is grabbed, which it is. The commit that introduced relevant parts is: https://git.gnome.org/browse/gtk+/commit/?id=bfee45e6f9f13506f97c8765255c7dc0dd698420 Thanks for looking into this.
I don't think the events being consumed by gdk or gtk is relevant, what's probably relevant though is that GdkSeats create an active grab on the keyboard, instead of the bunch of passive key grabs, so the compositor can't grab again for is own keycombos.
As a workaround I replaced 2667: if (gdk_seat_grab (seat, x11_context->ipc_window, GDK_SEAT_CAPABILITY_ALL, FALSE, x11_context->cursor, NULL, NULL, NULL) != GDK_GRAB_SUCCESS) return FALSE; with: if (gdk_seat_grab (seat, x11_context->ipc_window, GDK_SEAT_CAPABILITY_ALL_POINTING, FALSE, x11_context->cursor, NULL, NULL, NULL) != GDK_GRAB_SUCCESS) return FALSE; Works fine so far.
*** Bug 764995 has been marked as a duplicate of this bug. ***
This happens for me in Firefox 47 as well, after upgrading gtk3. When I select text and want to drag it to another window, I try to use alt-tab. But that doesn't work, all keyboard activity is shallowed (including hotkeys and things like volume control). Known good version: GTK 3.18.9 First known bad version: GTK 3.20.3 OS: ArchLinux, independent of window manager (tried KDE (X11), i3wm) The above steps works in Firefox 42 on ArchLinux, but this version of Firefox is linked against GTK2. While trying to find the offending commit (by looking at code changes, not by compiling it), I also found https://git.gnome.org/browse/gtk+/commit/?id=bfee45e6f9f13506f97c8765255c7dc0dd698420 suspicious (this one was also mentioned in comment 2 by the OP).
This was fixed in 3.20.4, as well as master: https://git.gnome.org/browse/gtk+/commit/?h=gtk-3-20&id=6f2187270e914f3da018e1bcc4278c0c2c9eb042
It is NOT fixed in 3.20.4. The first known bad is 3.20.3 (comment 6), but at the time of posting my comment, I was using 3.20.5. Now I'm using 3.20.6 and I still cannot use alt-tab in Firefox while dragging. gtk3 on ArchLinux is compiled using X11 instead of xinput2: https://www.archlinux.org/packages/extra/x86_64/gtk3/ https://git.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/gtk3&id=746d19a979987fcdeb732304733bf71dd078119c CXX=/bin/false ./configure --prefix=/usr \ --sysconfdir=/etc \ --localstatedir=/var \ --disable-schemas-compile \ --enable-x11-backend \ --enable-broadway-backend \ --enable-wayland-backend Why does is your "fix" only applied to the XINPUT_2 target, and not also x11?
That's the main reason why I'm using GTK2 version downloaded from somewhere. Why not use "GDK_SEAT_CAPABILITY_ALL_POINTING" for every event?
the !XINPUT_2 paths were phased out >6 years ago. If they were made to work back then is because XI2 was still fairly new, so distros might have recent enough Xserver and libraries or not. Nowadays, there's no such concerns because all distros use XI2-capable X servers, and you should really have no reasons to want to avoid XI2, this was not meant to be a user toggle. Also, a large number of features that has been added during these 6+ years will just break in more or less subtle ways if you use core events (eg. gestures, touch support, GdkSeat, ...). If your request was "please implement this too for core events". Sorry but that won't happen, we already have 4 windowing backends to care about, our intent here is to simplify maintenance, not to make it worse than it is now for no clear reason.
Pretty sure Arch does *not* disable XInput2 support, so whether the commit is right or not because of XInput2/Core events is inconsequential. Firefox, on the other hand, may still be disabling multi-device support — which would disable a whole lot of XInput code paths. This should be addressed in Firefox.
> Pretty sure Arch does *not* disable XInput2 support My bad. I was assuming that the --enable-x11-backend somehow disabled XINPUT_2. I stand corrected. > Firefox, on the other hand, may still be disabling multi-device support — which would disable a whole lot of XInput code paths. This should be addressed in Firefox. This used to work in Firefox with gtk 3.18.9, so this backwards-incompatible change may also happen with applications other than Firefox. I'll just trust your judgements on what should happen here. Thanks to your pointer, I found that using the following environment variable solves my issue (on Mozilla's bugzilla). MOZ_USE_XINPUT2=1
(In reply to Rob Wu from comment #12) > > Firefox, on the other hand, may still be disabling multi-device support — which would disable a whole lot of XInput code paths. This should be addressed in Firefox. > > This used to work in Firefox with gtk 3.18.9, so this backwards-incompatible > change may also happen with applications other than Firefox. I'll just trust > your judgements on what should happen here. It used to work because the input system was not using features disabled by Firefox. The API Firefox is using was meant as a transitional step in the last days of GTK 2 and early days of GTK 3; I honestly don't know why Firefox is still using it.