Dragging text or a tab blocks window manager keyboard shortcuts

NEW
Unassigned

Status

()

P3
normal
2 years ago
3 months ago

People

(Reporter: jamesbunton, Unassigned)

Tracking

(Blocks: 2 bugs)

46 Branch
x86_64
Linux
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox59 affected)

Details

(Whiteboard: tpi:+)

(Reporter)

Description

2 years ago
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
(Reporter)

Updated

2 years ago
OS: Unspecified → Linux
Hardware: Unspecified → x86_64

Comment 1

2 years ago
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)
(Reporter)

Comment 2

2 years ago
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)

Comment 3

2 years ago
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.
(Reporter)

Comment 4

2 years ago
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!
(Reporter)

Comment 5

2 years ago
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

2 years ago
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)
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

Updated

2 years ago
Priority: -- → P3
Whiteboard: tpi:+

Updated

2 years ago
Duplicate of this bug: 1299447

Updated

7 months ago
Duplicate of this bug: 1307750
Duplicate of this bug: 1420770
Duplicate of this bug: 1428824
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.

Comment 15

7 months ago
(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)

Comment 17

7 months ago
Thanks! I'm dropping this back to a P3 (backlog).
Flags: needinfo?(jmathies)
Priority: P2 → P3
You need to log in before you can comment on or make changes to this bug.