Open Bug 1276449 Opened 8 years ago Updated 2 years ago

[x11] Dragging text or a tab blocks window manager keyboard shortcuts

Categories

(Core :: Widget: Gtk, defect, P3)

Product:
Core
Component:
Widget: Gtk
Version:
46 Branch
Platform:
x86_64
Linux
Type:
defect

Tracking

()

Tracking Flags:
Tracking Status
firefox59 --- affected

People

(Reporter: jamesbunton, Unassigned)

References

(Depends on 1 open bug, Blocks 2 open bugs)

Details

(Keywords: regression, Whiteboard: tpi:+)

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:46.0) Gecko/20100101 Firefox/46.0 Build ID: 20160503215307 Steps to reproduce: 1. Select some text on any page 2. Click and hold to drag the text, do not release the mouse button 3. Press a window manager keyboard shortcut, for example Alt-Tab Actual results: Nothing, the window manager doesn't seem to ever get any key presses while the mouse button is held down. This issue is reproducible in the latest Firefox 46.0.1 release. The first Firefox nightly to have this issue is: https://ftp.mozilla.org/pub/firefox/nightly/2015/09/2015-09-24-03-02-31-mozilla-central/firefox-44.0a1.en-US.linux-x86_64.tar.bz2 Expected results: The window manager should receive key presses even if the mouse is held down. The last Firefox nightly which did not have this issue is: https://ftp.mozilla.org/pub/firefox/nightly/2015/09/2015-09-23-03-02-30-mozilla-central/firefox-44.0a1.en-US.linux-x86_64.tar.bz2
OS: Unspecified → Linux
Hardware: Unspecified → x86_64
User Agent Mozilla/5.0 (X11; Linux x86_64; rv:49.0) Gecko/20100101 Firefox/49.0 Build ID 20160530071207 I could not reproduce the issue on latest Nightly (49.0a1) and on current release (46.0.1), neither with the two build that you provided. On all this versions ALT+Tab worked as expected. I'm using Ubuntu 15.04. On what OS do you see the issue? Can you try in Safe Mode (https://support.mozilla.org/en-US/kb/troubleshoot-firefox-issues-using-safe-mode) and with a new profile (https://support.mozilla.org/en-US/kb/profile-manager-create-and-remove-firefox-profiles) to see if the issue is still reproducible?
Flags: needinfo?(jamesbunton)
Hi Liviu, thanks for looking at this for me :) I'm using Arch Linux with XFCE4. The problem occurs with both Xmonad as the window manager as well as the default XFWM4. I have tested and the issue does occur when I create a new profile and run that profile in safe mode. Strangely I cannot reproduce this on Ubuntu either. I booted a fresh Ubuntu live-iso and tested with both Unity and XFCE4 with the latest Firefox, the problem did not occur. Ubuntu and Arch are both using the same Xorg version and XFCE4 versions. It can't be any distro-specific patches to Firefox because I can reproduce the problem with the Mozilla nightly images. It is possible that there are distro-specific patches to Xorg or XFCE4 which are affecting it. I was able to reproduce it with a fresh Arch Linux live-iso boot. If you want to try that here are the steps to follow: 1. Boot archlinux-2016.05.01-dual.iso 2. Allocate more memory to the COW tmpfs: # mount -o remount,size=2G /run/archiso/cowspace 3. Update everything: # pacman -Syu 4. Install a GUI, say yes to everything: # pacman -S xorg xfce4 firefox xterm 5. Create a user: # useradd -m dummy-user && passwd -d dummy-user 6. Switch to VT2: Press ALT-F2 7. Login with your newly created user 8. Start the GUI: $ startxfce4 9. Run Firefox Otherwise if you can think of anything else I can try to narrow it down I'd be happy to do that :) Thanks again!
Flags: needinfo?(jamesbunton)
Thanks for the info. Unfortunately I can't test on Arch Linux. One thing that can help is to find a regression range. I see you provided last good build and first bad build in the initial report, but it may be more helpful to have the pushlog that contains the changes that were made when the issue appeared. You can do that using mozregression tool(http://mozilla.github.io/mozregression/). Basically you provide the last good build date and first bad build date and it will download and open for you nightly builds. You have to check if the bug exist in that build or not, and flag it as good or bad. Finally you will receive a pushlog. Please copy and paste that pushlog here.
I extracted the changesets from the platform.ini file in the two builds I mentioned. Here's the pushlog: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=19b4265d0d568d232fb3a34705f947b6db7496dc&tochange=bf2bc1aa78c0b72d9b6b13f7a8c6ae61c60a51dc There's quite a lot there!
I did a bisect and tracked it down to this commit: https://hg.mozilla.org/mozilla-central/rev/e7017f284e77 I checked the latest version and there's a MOZ_USE_XINPUT2 environment variable! Setting MOZ_USE_XINPUT2=1 completely fixes the problem for me. Also I get smooth scrolling! :D
Great. You did a good job narrowing down to one commit. Andrew, can you have a look at this, please?
Blocks: 1170342
Status: UNCONFIRMED → NEW
Component: Untriaged → Widget: Gtk
Ever confirmed: true
Flags: needinfo?(andrew)
Product: Firefox → Core
It appears that when a drag and drop event begins, upstream GDK creates a grab on all pointer and keyboard events by calling gdk_seat_grab in gdk/x11/gdkdnd-x11.c. This would suggest that GDK's XInput 2 backend is not respecting the keyboard grab, which is actually an upstream bug. I don't think this is too concerning for now, but we do plan on re-enabling XInput 2 in the near future.
Flags: needinfo?(andrew)
Priority: -- → P3
Whiteboard: tpi:+
Priority: P3 → P2
From bug 1428824, looks like drag and drop is also broken (in 59, but not sure when that issue began). Jim, given that we have several duplicate issues, does this still look like a gtk problem or is it something we can work around in Firefox?
status-firefox59: --- → affected
Flags: needinfo?(jmathies)
See https://bugzilla.mozilla.org/show_bug.cgi?id=1182700#c40 and further. We can fix this but the fix introduces a regression at scrolling: https://bugzilla.mozilla.org/show_bug.cgi?id=1182700#c40 and focus handling: https://bugzilla.mozilla.org/show_bug.cgi?id=1182700#c44 I believe the focus handling can be fixed and I'll look at it. The scrolling issue is abandoned by Gtk+ guys and I don't know how to workaround it. Only fix here is to switch to native Wayland port.
(In reply to Martin Stránský [:stransky] from comment #14) > See https://bugzilla.mozilla.org/show_bug.cgi?id=1182700#c40 and further. > > We can fix this but the fix introduces a regression at scrolling: > https://bugzilla.mozilla.org/show_bug.cgi?id=1182700#c40 > > and focus handling: > https://bugzilla.mozilla.org/show_bug.cgi?id=1182700#c44 > > I believe the focus handling can be fixed and I'll look at it. The scrolling > issue is abandoned by Gtk+ guys and I don't know how to workaround it. Only > fix here is to switch to native Wayland port. Hey Martin, so this regressed when we disabling XINPUT2 in bug 1170342? Sounds like we have a work around (comment 5) for users who do not like the new behavior. Do you know if a bug has been filed on the focus issue?
Flags: needinfo?(stransky)
(In reply to Jim Mathies [:jimm] from comment #15) > (In reply to Martin Stránský [:stransky] from comment #14) > > See https://bugzilla.mozilla.org/show_bug.cgi?id=1182700#c40 and further. > > > > We can fix this but the fix introduces a regression at scrolling: > > https://bugzilla.mozilla.org/show_bug.cgi?id=1182700#c40 > > > > and focus handling: > > https://bugzilla.mozilla.org/show_bug.cgi?id=1182700#c44 > > > > I believe the focus handling can be fixed and I'll look at it. The scrolling > > issue is abandoned by Gtk+ guys and I don't know how to workaround it. Only > > fix here is to switch to native Wayland port. > > Hey Martin, so this regressed when we disabling XINPUT2 in bug 1170342? Yes, exactly. This bug is a regression caused by disabled XINPUT2 by default. > Sounds like we have a work around (comment 5) for users who do not like the > new behavior. Yes, the MOZ_USE_XINPUT2 variable can be set and that fixes Alt+Tab switching. Fedora distro has this workaround enabled since it was introduced (~2 years ago) and I don't have any complains about focus/scrolling it so far. I'd say it's safe to enable it again for distros with recent Gtk+/X11 versions. > Do you know if a bug has been filed on the focus issue? Don't know, we may file a new one from Bug 1182700 comment 44. I tried to reproduce that but without any luck.
Flags: needinfo?(stransky)
Thanks! I'm dropping this back to a P3 (backlog).
Flags: needinfo?(jmathies)
Priority: P2 → P3

Bugbug thinks this bug is a regression, but please revert this change in case of error.

Keywords: regression

I have the same problem with Kubuntu 20.04 (KDE window manager) and exporting MOZ_USE_XINPUT2 also works around this problem. Can this behaving be set on by default?

In fact it was just made the default setting a few days ago. :)

Severity: normal → S3

The severity field for this bug is relatively low, S3. However, the bug has 6 duplicates.
:stransky, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Flags: needinfo?(stransky)

The last needinfo from me was triggered in error by recent activity on the bug. I'm clearing the needinfo since this is a very old bug and I don't know if it's still relevant.

Flags: needinfo?(stransky)

This is still an issue, on Ubuntu LTS Jammy, using Firefox beta 112b (deb), two separate devices, after fresh distro install

Try running MOZ_ENABLE_WAYLAND=1 firefox from the terminal to use native Wayland. If that works, you can make it permanent by adding export MOZ_ENABLE_WAYLAND=1 to your ~/.profile (restart/logout to take effect).

(In reply to Kestrel from comment #26)

Try running MOZ_ENABLE_WAYLAND=1 firefox from the terminal to use native Wayland.

This ticket is about X11. As far as I can tell this was never an issue on Wayland.

Works for me on KDE Wayland, Debian Testing.

Depends on: wayland-stable

(In reply to Oded Arbel from comment #27)

(In reply to Kestrel from comment #26)

Try running MOZ_ENABLE_WAYLAND=1 firefox from the terminal to use native Wayland.

This ticket is about X11. As far as I can tell this was never an issue on Wayland.

Indeed, the issue is reproducible on X11, will check on Wayland later.
Adding the flag on X11 doesn't change anything, and prints no additional logs

(In reply to Darkspirit from comment #28)

Works for me on KDE Wayland, Debian Testing.

Why depend on wayland-stable if the issue is for X11 ?

Blocks: linuxdad
Summary: Dragging text or a tab blocks window manager keyboard shortcuts → [x11] Dragging text or a tab blocks window manager keyboard shortcuts

(In reply to Abderrahim Digourdi [:adigo] from comment #29)

Why depend on wayland-stable if the issue is for X11 ?

Either legacy X11 would be fixed by bug 1207700 or this is wontfix (=fixed by wayland).

You need to log in before you can comment on or make changes to this bug.