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

Status: NEW

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

Description

[James Bunton]

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

Comment 1

[Liviu Cirdei]

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?

Comment 2

[James Bunton]

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!

Comment 3

[Liviu Cirdei]

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.

Comment 4

[James Bunton]

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!

Comment 5

[James Bunton]

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

Comment 6

[Liviu Cirdei]

Great. You did a good job narrowing down to one commit. 

Andrew, can you have a look at this, please?

Comment 7

[Andrew Comminos [:acomminos]]

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.

Comment 8

[Karl Tomlinson (:karlt)]

https://bugzilla.gnome.org/show_bug.cgi?id=764605#c6 says this is a GTK 3.20 regression.

Looks like it was fixed only for XI2.  I don't know why that would be.

https://git.gnome.org/browse/gtk+/commit/?h=gtk-3-20&id=6f2187270e914f3da018e1bcc4278c0c2c9eb042

Comment 13

[Liz Henry (:lizzard) (relman/hg->git project)]

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?

Comment 14

[Martin Stránský [:stransky] (ni? me)]

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.

Comment 15

[Jim Mathies [:jimm]]

(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?

Comment 16

[Martin Stránský [:stransky] (ni? me)]

(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.

Comment 17

[Jim Mathies [:jimm]]

Thanks! I'm dropping this back to a P3 (backlog).

Comment 19

[BugBot [:suhaib / :marco/ :calixte]]

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

Comment 20

[Oded Arbel]

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?

Comment 21

[Nate Graham]

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

Comment 23

[BugBot [:suhaib / :marco/ :calixte]]

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.

Comment 24

[BugBot (nomail) [:suhaib / :marco/ :calixte]]

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.

Comment 25

[Abderrahim Digourdi [:adigo]]

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

Comment 26

[Kestrel]

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).

Comment 27

[Oded Arbel]

(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.

Comment 28

[Darkspirit]

Works for me on KDE Wayland, Debian Testing.

Comment 29

[Abderrahim Digourdi [:adigo]]

(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 ?

Comment 30

[Darkspirit]

(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).