Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 715604 - www-client/firefox{,-bin}: MOZ_USE_XINPUT2=1 set by wrapper breaks mouse wheel scrolling
Summary: www-client/firefox{,-bin}: MOZ_USE_XINPUT2=1 set by wrapper breaks mouse whee...
Status: CONFIRMED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal with 1 vote (vote)
Assignee: Mozilla Gentoo Team
URL:
Whiteboard:
Keywords:
: 715722 716230 (view as bug list)
Depends on:
Blocks:
 
Reported: 2020-03-31 11:37 UTC by Nikos Chantziaras
Modified: 2020-08-19 19:51 UTC (History)
15 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
Xorg.log (Xorg.0.log,38.26 KB, text/plain)
2020-04-01 20:29 UTC, cruzki
Details
Xorg.0.log (Xorg.0.log,25.99 KB, text/plain)
2020-04-01 22:24 UTC, Nikos Chantziaras
Details
My Xorg.0.log (Xorg.0.log,146.95 KB, text/x-log)
2020-04-01 23:14 UTC, superjaded
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Nikos Chantziaras 2020-03-31 11:37:30 UTC
Upgraded to www-client/firefox-bin-74.0-r1 and this broke mouse wheel scrolling after a while. Restarting the browser fixes it, but after between 10 to 20 minutes, it stops working again.

Furthermore, the mouse wheel does not work at all when the firefox window does not have focus. This is not normal behavior on Linux in general; you can scroll in application using the mouse even if the application window does not have focus.

Deleting this line:

export MOZ_USE_XINPUT2=1

in /usr/bin/firefox-bin fixes these issues.
Comment 1 Nikos Chantziaras 2020-03-31 11:37:55 UTC
$ emerge --info firefox-bin
Portage 2.3.96 (python 3.8.2-final-0, default/linux/amd64/17.0/desktop/plasma/systemd, gcc-9.2.0, glibc-2.30-r6, 5.4.28-gentoo x86_64)
=================================================================
                         System Settings
=================================================================
System uname: Linux-5.4.28-gentoo-x86_64-Intel-R-_Core-TM-_i5-2500K_CPU_@_3.30GHz-with-glibc2.4
KiB Mem:    16367672 total,   8570212 free
KiB Swap:    4194300 total,   4194300 free
Timestamp of repository gentoo: Tue, 31 Mar 2020 10:09:12 +0000
Head commit of repository gentoo: 8566fa3a6f816e23bed8a26b74eaecf407751603

Head commit of repository flatpak-overlay: ea16fa7c90c16c8720e4a388e7ddcdd70ad30221

sh bash 5.0_p16
ld GNU ld (Gentoo 2.34 p1) 2.34.0
app-shells/bash:          5.0_p16::gentoo
dev-lang/perl:            5.30.1::gentoo
dev-lang/python:          2.7.17-r1::gentoo, 3.6.10::gentoo, 3.7.7::gentoo, 3.8.2::gentoo
dev-util/cmake:           3.17.0::gentoo
dev-util/pkgconfig:       0.29.2::gentoo
sys-apps/baselayout:      2.7::gentoo
sys-apps/sandbox:         2.18::gentoo
sys-devel/autoconf:       2.13-r1::gentoo, 2.69-r5::gentoo
sys-devel/automake:       1.16.2::gentoo
sys-devel/binutils:       2.34::gentoo
sys-devel/gcc:            9.2.0-r4::gentoo
sys-devel/gcc-config:     2.2.1::gentoo
sys-devel/libtool:        2.4.6-r6::gentoo
sys-devel/make:           4.3::gentoo
sys-kernel/linux-headers: 5.6::gentoo (virtual/os-headers)
sys-libs/glibc:           2.30-r6::gentoo
Repositories:

gentoo
    location: /mnt/Data/gentoo/portage
    sync-type: git
    sync-uri: https://anongit.gentoo.org/git/repo/sync/gentoo.git
    priority: -1000
    sync-git-verify-commit-signature: true

flatpak-overlay
    location: /usr/local/flatpak-overlay
    sync-type: git
    sync-uri: https://github.com/fosero/flatpak-overlay.git
    masters: gentoo
    priority: 50

interactive-fiction
    location: /var/lib/layman/interactive-fiction
    masters: gentoo
    priority: 50

seden
    location: /var/lib/layman/seden
    masters: gentoo
    priority: 50

steam-overlay
    location: /var/lib/layman/steam-overlay
    masters: gentoo
    priority: 50

vapoursynth
    location: /var/lib/layman/vapoursynth
    masters: gentoo
    priority: 50

local
    location: /usr/local/portage
    masters: gentoo
    priority: 9999999

ACCEPT_KEYWORDS="amd64 ~amd64"
ACCEPT_LICENSE="*"
CBUILD="x86_64-pc-linux-gnu"
CFLAGS="-pipe -O2 -mtune=native -march=native -ftree-vectorize"
CHOST="x86_64-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/share/config /usr/share/gnupg/qualified.txt"
CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/dconf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo /etc/texmf/language.dat.d /etc/texmf/language.def.d /etc/texmf/updmap.d /etc/texmf/web2c /etc/vmware-installer"
CXXFLAGS="-pipe -O2 -mtune=native -march=native -ftree-vectorize"
DISTDIR="/mnt/Data/gentoo/distfiles"
EMERGE_DEFAULT_OPTS="--backtrack=200"
ENV_UNSET="DBUS_SESSION_BUS_ADDRESS DISPLAY GOBIN PERL5LIB PERL5OPT PERLPREFIX PERL_CORE PERL_MB_OPT PERL_MM_OPT XAUTHORITY XDG_CACHE_HOME XDG_CONFIG_HOME XDG_DATA_HOME XDG_RUNTIME_DIR"
FCFLAGS="-pipe -O2 -mtune=native -march=native -ftree-vectorize"
FEATURES="assume-digests binpkg-docompress binpkg-dostrip binpkg-logs config-protect-if-modified distlocks ebuild-locks fixlafiles ipc-sandbox merge-sync multilib-strict network-sandbox news parallel-fetch pid-sandbox preserve-libs protect-owned qa-unresolved-soname-deps sandbox sfperms sign strict unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersandbox usersync xattr"
FFLAGS="-pipe -O2 -mtune=native -march=native -ftree-vectorize"
GENTOO_MIRRORS="http://ftp.ntua.gr/pub/linux/gentoo http://gentoo.mirrors.ovh.net/gentoo-distfiles http://distfiles.gentoo.org"
LANG="en_US.UTF-8"
LDFLAGS="-Wl,-O1 -Wl,--as-needed"
LINGUAS="en_US en"
MAKEOPTS="-j4"
PKGDIR="/mnt/Data/gentoo/packages"
PORTAGE_CONFIGROOT="/"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --omit-dir-times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages --exclude=/.git"
PORTAGE_TMPDIR="/var/tmp"
USE="X a52 aac accessibility acl acpi activities amd64 berkdb bzip2 cairo cli crypt dbus declarative dri dts dvd dvdr emboss encode exif flac fortran gdbm gif gpm gtk iconv icu ipv6 jpeg kde kipi kwallet lcms libnotify libtirpc linguas_en linguas_en_US lto mad mng mp3 mp4 mpeg multilib ncurses nptl nvidia offensive ogg opengl openmp pam pango pcre pdf pgo phonon plasma png policykit ppds pulseaudio qml qt5 readline seccomp spell split-usr ssl startup-notification svg systemd tcpd tiff truetype udev udisks unicode upower usb vdpau vorbis vulkan wayland widgets wxwidgets xattr xcb xcomposite xml xv xvid zlib" ABI_X86="64 32" ADA_TARGET="gnat_2018" APACHE2_MODULES="authn_core authz_core socache_shmcb unixd actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache cgi cgid dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" CALLIGRA_FEATURES="karbon sheets words" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" CPU_FLAGS_X86="aes avx mmx mmxext pclmul popcnt sse sse2 sse3 sse4_1 sse4_2 ssse3" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock greis isync itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf skytraq superstar2 timing tsip tripmate tnt ublox ubx" GRUB_PLATFORMS="efi-64" INPUT_DEVICES="libinput keyboard mouse" KERNEL="linux" L10N="en-US en" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LIBREOFFICE_EXTENSIONS="presenter-console presenter-minimizer" OFFICE_IMPLEMENTATION="libreoffice" PHP_TARGETS="php7-2" POSTGRES_TARGETS="postgres10 postgres11" PYTHON_SINGLE_TARGET="python3_6" PYTHON_TARGETS="python2_7 python3_6 python3_7 python3_8" RUBY_TARGETS="ruby25" USERLAND="GNU" VIDEO_CARDS="nvidia" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account"
Unset:  CC, CPPFLAGS, CTARGET, CXX, INSTALL_MASK, LC_ALL, PORTAGE_BINHOST, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS

=================================================================
                        Package Settings
=================================================================

www-client/firefox-bin-74.0-r1::gentoo was built with the following:
USE="ffmpeg pulseaudio startup-notification wayland -alsa (-selinux)" ABI_X86="(64)" L10N="-ach -af -an -ar -ast -az -be -bg -bn -br -bs -ca -cak -cs -cy -da -de -dsb -el -en-CA -en-GB -eo -es-AR -es-CL -es-ES -es-MX -et -eu -fa -ff -fi -fr -fy -ga -gd -gl -gn -gu -he -hi -hr -hsb -hu -hy -ia -id -is -it -ja -ka -kab -kk -km -kn -ko -lij -lt -lv -mk -mr -ms -my -nb -nl -nn -oc -pa -pl -pt-BR -pt-PT -rm -ro -ru -si -sk -sl -son -sq -sr -sv -ta -te -th -tr -uk -ur -uz -vi -xh -zh-CN -zh-TW"
Comment 2 Jory A. Pratt gentoo-dev 2020-04-01 00:12:23 UTC
(In reply to Nikos Chantziaras from comment #0)
> Upgraded to www-client/firefox-bin-74.0-r1 and this broke mouse wheel
> scrolling after a while. Restarting the browser fixes it, but after between
> 10 to 20 minutes, it stops working again.
> 
> Furthermore, the mouse wheel does not work at all when the firefox window
> does not have focus. This is not normal behavior on Linux in general; you
> can scroll in application using the mouse even if the application window
> does not have focus.
> 
> Deleting this line:
> 
> export MOZ_USE_XINPUT2=1
> 
> in /usr/bin/firefox-bin fixes these issues.

This is what happens when developers are blindly doing things that they do not have a full understanding of.
Comment 3 Thomas Deutschmann gentoo-dev Security 2020-04-01 01:26:19 UTC
Could you please share more details about system?

I am wondering why this is working at the beginning for you but will stop after some time.
Comment 4 Klaus Ethgen 2020-04-01 06:48:38 UTC
Hello, I also got that bug when using firefox inside of a VM. But I have no mouse wheel functionality at all inside that machine. Installing the version 74.0 (from binpkg) fixes the issue.

Currently I masked =www-client/firefox-bin-74.0-r1 to prevent it from getting updated.

Please, whatever you did to break this, revert it as without mouse wheel, a browser is not that much usable.
Comment 5 Klaus Ethgen 2020-04-01 07:01:39 UTC
Ah, now I see the problem. It is about GTK3. This variable activate the broken GTK3 scrolling.

As I understand it from https://bugzilla.mozilla.org/show_bug.cgi?id=1182700, you should set `export GDK_CORE_DEVICE_EVENTS=1` when you activate XI2 support. But if I see that correct, you could better not even activate that XI2 support in GTK3.

Unfortunately, many applications break completely when been ported to GTK3 caused of this. This is also the reason why we in geeqie team still deliver the release packages with deactivated GTK3.

And yes. I see that as a example of ignorant developers not caring for their user base. They just focus a limited user base who uses wayland. But I never got wayland to work. Might be caused as I use fvwm2 as a window manager. I refuse that unusable gnome world as good as I can but with GTK one is bound to there goodwill.
Comment 6 Thomas Deutschmann gentoo-dev Security 2020-04-01 12:54:05 UTC
Without knowing or understanding the trigger, for now I can just say that this isn't a general problem. It looks like this issue is only affecting a small number of users.

What we need to understand now is the trigger.

Please share details of your used desktop environment (including ebuild version), GTK+ version and any other configuration which you believe could cause this.

Please elaborate your statement regarding gtk+-2, too. Are you still using gtk+-2? Even with firefox?
Comment 7 Piotr Karbowski archtester Gentoo Infrastructure gentoo-dev Security 2020-04-01 13:05:54 UTC
Hello there,

I actually had issue like described here on single Gentoo system, where mouse scroll would randomly just not work until Firefox restart, but it was on the source firefox, not binary package.

The characteristics of this system were that I was *not* using udev there, and because of that, I was using mousedrv there. Now that I switched back to udev, the inputs are handled by libinput and no such issue hit me since.

Can those of you that can reproduce it share with me the Xorg.0.log, so I can check what driver you uses?
Comment 8 Klaus Ethgen 2020-04-01 13:31:53 UTC
The issue with mouse wheel is a common trouble of GTK3. See the link into firefox bug tracker. It doesn't happen which version of GTK3, all are affected, there is no fixed version out there.

The link to GTK2 was made for Geeqie image viewer where I am one of the authors.

And see also the environment variable GDK_CORE_DEVICE_EVENTS which I mentioned.

I have no idea when the bug is NOT seen. I always have it. I think, maybe when you use gnome window manager, this issue is no issue. Or when using systemd (I use gentoo to not need to hav that systemd anywhere on my system!)
Comment 9 Nikos Chantziaras 2020-04-01 13:37:30 UTC
> Please share details of your used desktop environment (including ebuild version), GTK+ version and any other configuration which you believe could cause this.

www-client/firefox-bin-74.0-r1
~amd64
Kernel 5.4.28-gentoo (sys-kernel/gentoo-sources-5.4.28)
systemd 245
KDE Plasma 5.18.3
Gtk+ 2.24.32-r1 and 3.24.16 are installed
NVidia binary driver (x11-drivers/nvidia-drivers-440.64)
xorg-server 1.20.8
Comment 10 cruzki 2020-04-01 20:29:42 UTC
Created attachment 628610 [details]
Xorg.log

I have the same problem as described. As and added note I have had the same issue with libreoffice (both source and bin) for quite some time. 

Attached a Xorg.log form my system. 

Mostly stable system with some ~amd64 packages

www-client/firefox-bin (74.0-r1@30/03/20)
x11-base/xorg-server (1.20.7(0/1.20.7)@08/03/20)
5.6.0-gentoo
KDE Plasma 5.18.3
x11-libs/gtk+ (2.24.32-r1(2)@22/04/19 3.24.13(3)@12/02/20)

I do not know what more I can do to help debug this as is quite annoying.
Comment 11 Thomas Deutschmann gentoo-dev Security 2020-04-01 20:46:26 UTC
*** Bug 715722 has been marked as a duplicate of this bug. ***
Comment 12 Thomas Deutschmann gentoo-dev Security 2020-04-01 22:04:06 UTC
@ cruzki: Thanks. According to your attached log, you are using libinput. Comment #7 doesn't apply. We are back to zero :/
Comment 13 cruzki 2020-04-01 22:19:09 UTC
I there anything I can do to help debug this? The "hangs" seems completely at random. Is there a way to see where kwin is sending the mouse scroll information (to confirm that the information reach firefox or is stuck in other part of the stack)?
Comment 14 Nikos Chantziaras 2020-04-01 22:24:19 UTC
Created attachment 628616 [details]
Xorg.0.log

> Can those of you that can reproduce it share with me the Xorg.0.log, so I can check what driver you uses?

Attached.
Comment 15 superjaded 2020-04-01 23:14:02 UTC
Created attachment 628618 [details]
My Xorg.0.log
Comment 16 superjaded 2020-04-01 23:14:26 UTC
www-client/firefox-74.0-r2
kernel 5.4.28-gentoo
openrc
KDE Plasma 5.18.3
x11-libs/gtk+ 2.24.32-r1, 3.24.13
amdgpu 19.1.0, mesa 20.0.2

The behavior on my system seems to be slightly different than what other people describing. Rather than completely not working, my mousewheel only seems to work (generally, not just fiefox) on GTK apps when the windows have focus. 

Let's say I have a firefox window open and a dolphin window.

If the dolphin window has focus and I hover over the firefox window, nothing happens.
If the firefox window has focus and i hover over the dolphin window, it scrolls up and down like I would expect.

I wasn't sure if this was exactly the same bug as others have reported due to the discrepancies between my experience and others, but when I restarted Firefox with the MOZ_USE_XINPUT2 setting commented out of /usr/bin/firefox, the mousewheel went back to working as I expected, namely being able to scroll up and down without the window having focus.
Comment 17 Perfect Gentleman 2020-04-02 08:33:00 UTC
'GDK_CORE_DEVICE_EVENTS=1 firefox' works fine.
Comment 18 Thomas Deutschmann gentoo-dev Security 2020-04-02 09:08:33 UTC
Is anyone affected without using kwin?
Or is a kwin user affected who uses wayland?
Comment 19 superjaded 2020-04-02 09:59:50 UTC
I can confirm Perfect Gentleman's suggestion about GDK_CORE_DEVICE_EVENTS works for me as well for all of the GTK apps that I've noticed the issue on (firefox, deluge, virt-manager). I was able to also uncomment MOZ_USE_XINPUT2 from /usr/bin/firefox and the mousewheel behavior remained as expected in terms of being able to use the mousewheel on GTK apps that did not have focus.
Comment 20 Thomas Deutschmann gentoo-dev Security 2020-04-02 10:45:30 UTC
(In reply to Chris from comment #19)
> I was able to also uncomment MOZ_USE_XINPUT2 from /usr/bin/firefox and
> the mousewheel behavior remained as expected in terms of being able to
> use the mousewheel on GTK apps that did not have focus.
Just for the records, "GDK_CORE_DEVICE_EVENTS=1" wil disable XINPUT2 usage in GDK while MOZ_USE_XINPUT2=1 would just tell firefox to listen to XINPUT2. But firefox cannot listen to XINPUT2 when XINPUT2 was already disabled in GDK itself. So setting GDK_CORE_DEVICE_EVENTS=1 will basically have the same effect like removing MOZ_USE_XINPUT2=1...

tl;dr
If GDK_CORE_DEVICE_EVENTS=1 is set, MOZ_USE_XINPUT2=1 has no effect.
Comment 21 Thomas Deutschmann gentoo-dev Security 2020-04-02 13:00:04 UTC
Based on reports and user feedback I plan to push the following changes for the wrapper script:

> --- old/usr/bin/firefox
> +++ new/usr/bin/firefox
> @@ -83,7 +83,25 @@ fi
>  ##
>  ## Enable Xinput2 (#617344)
>  ##
> -export MOZ_USE_XINPUT2=1
> +
> +# respect user settings
> +MOZ_USE_XINPUT2=${MOZ_USE_XINPUT2:-auto}
> +
> +if [[ ${MOZ_USE_XINPUT2} == auto && -n ${WAYLAND_DISPLAY} ]]; then
> +	# enabling XINPUT2 should be safe for all wayland users
> +	MOZ_USE_XINPUT2=1
> +elif [[ ${MOZ_USE_XINPUT2} == auto && ${XDG_CURRENT_DESKTOP^^} == KDE ]]; then
> +	# XINPUT2 is known to cause problems for kWin users
> +	MOZ_USE_XINPUT2=0
> +elif [[ ${MOZ_USE_XINPUT2} == auto && ${XDG_CURRENT_DESKTOP^^} == LXQT ]]; then
> +	# LXQt uses kWin
> +	MOZ_USE_XINPUT2=0
> +elif [[ ${MOZ_USE_XINPUT2} == auto ]]; then
> +	# should work on Mate, Xfce, FluxBox, OpenBox and all the others ...
> +	MOZ_USE_XINPUT2=1
> +fi
> +
> +[[ ${MOZ_USE_XINPUT2} != 0 ]] && export MOZ_USE_XINPUT2=${MOZ_USE_XINPUT2}
>  
>  # Don't throw "old profile" dialog box.
>  export MOZ_ALLOW_DOWNGRADE=1
Would be nice if you could test this and give feedback.
www-client/firefox-bin users have to change filename of course.
Comment 22 Nikos Chantziaras 2020-04-02 13:42:28 UTC
> Would be nice if you could test this and give feedback.
Works fine here with KWin.
Comment 23 Klaus Ethgen 2020-04-02 17:18:10 UTC
> --- old/usr/bin/firefox
> +++ new/usr/bin/firefox
> @@ -83,7 +83,25 @@ fi
>  ##
>  ## Enable Xinput2 (#617344)
>  ##
> -export MOZ_USE_XINPUT2=1
> +
> +# respect user settings
> +MOZ_USE_XINPUT2=${MOZ_USE_XINPUT2:-auto}
> +
> +if [[ ${MOZ_USE_XINPUT2} == auto && -n ${WAYLAND_DISPLAY} ]]; then
> +	# enabling XINPUT2 should be safe for all wayland users
> +	MOZ_USE_XINPUT2=1
> +elif [[ ${MOZ_USE_XINPUT2} == auto && ${XDG_CURRENT_DESKTOP^^} == KDE ]]; then
> +	# XINPUT2 is known to cause problems for kWin users
> +	MOZ_USE_XINPUT2=0
> +elif [[ ${MOZ_USE_XINPUT2} == auto && ${XDG_CURRENT_DESKTOP^^} == LXQT ]]; then
> +	# LXQt uses kWin
> +	MOZ_USE_XINPUT2=0
> +elif [[ ${MOZ_USE_XINPUT2} == auto ]]; then
> +	# should work on Mate, Xfce, FluxBox, OpenBox and all the others ...
> +	MOZ_USE_XINPUT2=1
> +fi
> +
> +[[ ${MOZ_USE_XINPUT2} != 0 ]] && export MOZ_USE_XINPUT2=${MOZ_USE_XINPUT2}
>  
>  # Don't throw "old profile" dialog box.
>  export MOZ_ALLOW_DOWNGRADE=1

That will also break on fvwm and maybe others. So that last elif should disable that crap.

This setting is only safe on gnome. On all other windowmanagers I expect troubles.
Comment 24 Klaus Ethgen 2020-04-02 17:22:18 UTC
> Is anyone affected without using kwin?

Yes, me! As I already wrote.

I use fvwm2.
Comment 25 Larry the Git Cow gentoo-dev 2020-04-02 21:18:58 UTC
The bug has been closed via the following commit(s):

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=4dd43c0f1c0520ad93b3b836aab06baedf8eb919

commit 4dd43c0f1c0520ad93b3b836aab06baedf8eb919
Author:     Thomas Deutschmann <whissi@gentoo.org>
AuthorDate: 2020-04-02 21:16:14 +0000
Commit:     Thomas Deutschmann <whissi@gentoo.org>
CommitDate: 2020-04-02 21:18:50 +0000

    www-client/firefox: don't enable XINPUT2 for KWin users
    
    Closes: https://bugs.gentoo.org/715604
    Package-Manager: Portage-2.3.96, Repoman-2.3.22
    Signed-off-by: Thomas Deutschmann <whissi@gentoo.org>

 www-client/firefox/files/firefox.sh                  | 20 +++++++++++++++++++-
 ...fox-68.6.0-r3.ebuild => firefox-68.6.0-r4.ebuild} |  0
 ...firefox-74.0-r2.ebuild => firefox-74.0-r3.ebuild} |  0
 3 files changed, 19 insertions(+), 1 deletion(-)

Additionally, it has been referenced in the following commit(s):

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=aab03537c23183b3cfd04c5d5524d89fb7ecc004

commit aab03537c23183b3cfd04c5d5524d89fb7ecc004
Author:     Thomas Deutschmann <whissi@gentoo.org>
AuthorDate: 2020-04-02 21:11:46 +0000
Commit:     Thomas Deutschmann <whissi@gentoo.org>
CommitDate: 2020-04-02 21:18:49 +0000

    www-client/firefox-bin: don't enable XINPUT2 for KWin users
    
    Bug: https://bugs.gentoo.org/715604
    Package-Manager: Portage-2.3.96, Repoman-2.3.22
    Signed-off-by: Thomas Deutschmann <whissi@gentoo.org>

 www-client/firefox-bin/files/firefox-bin.sh          | 20 +++++++++++++++++++-
 ...68.6.0-r1.ebuild => firefox-bin-68.6.0-r2.ebuild} |  0
 ...bin-74.0-r1.ebuild => firefox-bin-74.0-r2.ebuild} |  0
 3 files changed, 19 insertions(+), 1 deletion(-)
Comment 26 Thomas Deutschmann gentoo-dev Security 2020-04-02 21:27:40 UTC
We will see. Please post your XDG_CURRENT_DESKTOP value.
Maybe we will switch to a whitelist instead.

I keep this issue open to allow others to find this bug more easily for now.
Comment 27 Klaus Ethgen 2020-04-02 21:36:37 UTC
XDG_CURRENT_DESKTOP is only set in kde and gnome if I remember correct.

In fvwm that variable is not set.
Comment 28 Thomas Deutschmann gentoo-dev Security 2020-04-03 09:32:42 UTC
Please share environment. Is there any other variable to check for?
Comment 29 Andrew Church 2020-04-03 10:12:44 UTC
FVWM user here, I haven't had this problem myself but with respect to detecting FVWM:

FVWM doesn't provide a "desktop environment" in the sense of Gnome or KDE and doesn't (as far as I'm aware) set any environment variables in spawned processes, but it does follow ICCCM, so you can detect it via _NET_WM_NAME: (error checking omitted for brevity)

$ xprop -root _NET_SUPPORTING_WM_CHECK
_NET_SUPPORTING_WM_CHECK(WINDOW): window id # 0x160001a
$ xprop -id $(xprop -root _NET_SUPPORTING_WM_CHECK | sed -e 's/^.*# //') _NET_WM_NAME
_NET_WM_NAME(UTF8_STRING) = "FVWM"
Comment 30 tt_1 2020-04-03 22:24:58 UTC
I think I lost the ability to scroll with the middle mouse button, which is clicking and holding the mouse wheel itself, actually scrolling through by moving the mouse on the desk. 

My desktop is xfce4, and I think it worked with =firefox-74.0-r1
Comment 31 Thomas Deutschmann gentoo-dev Security 2020-04-03 22:59:48 UTC
If unsure, just start firefox with MOZ_USE_XINPUT2=0 set to test. Wrapper in latest ebuild will honor already set MOZ_USE_XINPUT2 variable.
Comment 32 Klaus Ethgen 2020-04-04 10:05:41 UTC
Today I read the last gentoo repository news about the deprecation of old x11-drivers/xf86-input-keyboard and x11-drivers/xf86-input-mouse.

They mention that there are two input drivers left to use: evdev (what I use and I think most are using) and libinput (that I even did not know to exist!)

So my question is, does all users using evdev for the mouse have troubles with this setting and only people (the minority I think) who use libinput driver benefit from this setting?

If that is the case, the switch should not check if one or the other window manager is in use than better which input driver is in use.

I guess, for gnome, that is all libinput as the gnome world is incompatible to all outside their mindset. But for anything else, maybe the evdev is the majority.
Comment 33 Klaus Ethgen 2020-04-04 10:10:51 UTC
> If unsure, just start firefox with MOZ_USE_XINPUT2=0 set to test. Wrapper in latest ebuild will honor already set MOZ_USE_XINPUT2 variable.

No, that would *not* work.

Let me quote from bash man page:

       ${parameter:-word}
              Use Default Values.  If parameter is unset or null, the expansion of word is substituted.  Oth-
              erwise, the value of parameter is substituted.

If the parameter is null (what it is in that case) the substitution take place which will be 1.
Comment 34 Thomas Deutschmann gentoo-dev Security 2020-04-04 11:46:38 UTC
Have you actually tested? "0" is not "null" (empty). To demonstrate, I enable trace mode:

> --- /usr/bin/firefox-bin.old    2020-04-04 13:38:04.577014832 +0200
> +++ /usr/bin/firefox-bin        2020-04-04 13:38:54.424502736 +0200
> @@ -84,6 +84,8 @@
>  ## Enable Xinput2 (#617344)
>  ##
> 
> +set -x
> +
>  # respect user settings
>  MOZ_USE_XINPUT2=${MOZ_USE_XINPUT2:-auto}
> 
> @@ -103,6 +105,8 @@
> 
>  [[ ${MOZ_USE_XINPUT2} != 0 ]] && export MOZ_USE_XINPUT2=${MOZ_USE_XINPUT2}
> 
> +set +x
> +
>  # Don't throw "old profile" dialog box.
>  export MOZ_ALLOW_DOWNGRADE=1
> 
> @@ -120,4 +124,4 @@
>  fi
> 
>  # Run the browser
> -exec ${MOZ_PROGRAM} "$@"
> +#exec ${MOZ_PROGRAM} "$@"

Now the test:

> thomas@vm-gentoo-x64 ~ $ firefox-bin
> + MOZ_USE_XINPUT2=auto
> + [[ auto == auto ]]
> + [[ -n '' ]]
> + [[ auto == auto ]]
> + [[ '' == KDE ]]
> + [[ auto == auto ]]
> + [[ '' == LXQT ]]
> + [[ auto == auto ]]
> + MOZ_USE_XINPUT2=1
> + [[ 1 != 0 ]]
> + export MOZ_USE_XINPUT2=1
> + MOZ_USE_XINPUT2=1
> + set +x
As expected, in "auto" mode, when no MOZ_USE_XINPUT2 is already set, you will probably end up with MOZ_USE_XINPUT2=1 in most cases.

> thomas@vm-gentoo-x64 ~ $ MOZ_USE_XINPUT2=0 firefox-bin
> + MOZ_USE_XINPUT2=0
> + [[ 0 == auto ]]
> + [[ 0 == auto ]]
> + [[ 0 == auto ]]
> + [[ 0 == auto ]]
> + [[ 0 != 0 ]]
> + set +x
However, when MOZ_USE_XINPUT2=0 is set, we do not set MOZ_USE_XINPUT2=1 and don't export anything.

And finally with MOZ_USE_XINPUT2 set to "null" (empty):

> thomas@vm-gentoo-x64 ~ $ MOZ_USE_XINPUT2= firefox-bin
> + MOZ_USE_XINPUT2=auto
> + [[ auto == auto ]]
> + [[ -n '' ]]
> + [[ auto == auto ]]
> + [[ '' == KDE ]]
> + [[ auto == auto ]]
> + [[ '' == LXQT ]]
> + [[ auto == auto ]]
> + MOZ_USE_XINPUT2=1
> + [[ 1 != 0 ]]
> + export MOZ_USE_XINPUT2=1
> + MOZ_USE_XINPUT2=1
> + set +x
Comment 35 Lars Wendler (Polynomial-C) gentoo-dev 2020-04-04 12:03:28 UTC
(In reply to Klaus Ethgen from comment #32)

Gentoo switched to libinput as default input driver more than three years ago (see bug #601132). 
This is not a "gnome" thing but the new default input method for both, xorg and wayland.
Comment 36 Nikos Chantziaras 2020-04-04 15:20:18 UTC
FWIW, even though libinput is the default, I explicitly use evdev for my mouse because I don't know how, if it's possible at all, to set acceleration and rate parameters with libinput. So I use:

Section "InputClass"
    Identifier "Logitech G502"
    Driver "evdev"
    MatchIsPointer "yes"
    Option "ExpectedRate" "1000"
    Option "AccelerationProfile" "-1"
    Option "AccelerationScheme" "none"
    Option "AccelSpeed" "-1"
EndSection
Comment 37 Thomas Deutschmann gentoo-dev Security 2020-04-05 21:30:16 UTC
*** Bug 716230 has been marked as a duplicate of this bug. ***
Comment 38 Gleb 2020-04-06 05:08:55 UTC
From ticket #716230:

answering to this question:
> Start firefox with MOZ_USE_XINPUT2=0 set and see if it makes any difference

It makes a huge difference, I already checked that before creating the new ticket.

So, MOZ_USE_XINPUT2=1 breaks Firefox on Xfce.
Comment 39 tt_1 2020-04-07 11:29:56 UTC
it doesn't work for me on xfce4 with firefox-75.0: 

env MOZ_USE_XINPUT2=1 /usr/bin/firefox breaks middle mouse button
env MOZ_USE_XINPUT2=0 /usr/bin/firefox breaks middle mouse button

scrolling with the mousewheel is untested, as my mouse fails to do that anyway
Comment 40 Thomas Deutschmann gentoo-dev Security 2020-04-07 13:43:20 UTC
(In reply to tt_1 from comment #39)
> it doesn't work for me on xfce4 with firefox-75.0: 
> 
> env MOZ_USE_XINPUT2=1 /usr/bin/firefox breaks middle mouse button
> env MOZ_USE_XINPUT2=0 /usr/bin/firefox breaks middle mouse button
> 
> scrolling with the mousewheel is untested, as my mouse fails to do that
> anyway
So you are saying that actually nothing is working for you. In this case, you have a different problem. This bug is about a change in Gentoo, that we are now setting MOZ_USE_XINPUT2=1 by default except for KWIN-based environments. But if you start firefox with MOZ_USE_XINPUT2=0 set, you are back to previous state and this change is basically reverted.
Comment 41 liushike1997 2020-04-08 08:13:53 UTC
(In reply to Thomas Deutschmann from comment #40)
> (In reply to tt_1 from comment #39)
> > it doesn't work for me on xfce4 with firefox-75.0: 
> > 
> > env MOZ_USE_XINPUT2=1 /usr/bin/firefox breaks middle mouse button
> > env MOZ_USE_XINPUT2=0 /usr/bin/firefox breaks middle mouse button
> > 
> > scrolling with the mousewheel is untested, as my mouse fails to do that
> > anyway
> So you are saying that actually nothing is working for you. In this case,
> you have a different problem. This bug is about a change in Gentoo, that we
> are now setting MOZ_USE_XINPUT2=1 by default except for KWIN-based
> environments. But if you start firefox with MOZ_USE_XINPUT2=0 set, you are
> back to previous state and this change is basically reverted.

Hi,stumpwm user test "env MOZ_USE_XINPUT2=0 /usr/bin/firefox" worked,but default not work
Comment 42 heydowns 2020-08-19 19:51:29 UTC
MOZ_USE_XINPUT2 unset (and evaluated to 1 at runtime by the firefox wrapper) breaks firefox menu interactions for me.  Menus open, but menu items within are not clickable.  The items can be accessed by keyboard input (up/down/enter) but not mouse/pointer clicks.  This applies to main menus (file/edit etc. and "three bar" main menu) as well as right-click context menu.

Force setting to MOZ_USE_XINPUT2=0 fixes this, restoring normal behavior.

Running inside xfce.  Happy to provide additional detail (or break out into separate bug) as needed.

(and yes, this was all tested with a clean/new firefox profile)