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.
$ 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"
(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.
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.
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.
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.
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?
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?
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!)
> 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
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.
*** Bug 715722 has been marked as a duplicate of this bug. ***
@ cruzki: Thanks. According to your attached log, you are using libinput. Comment #7 doesn't apply. We are back to zero :/
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)?
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.
Created attachment 628618 [details] My Xorg.0.log
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.
'GDK_CORE_DEVICE_EVENTS=1 firefox' works fine.
Is anyone affected without using kwin? Or is a kwin user affected who uses wayland?
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.
(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.
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.
> Would be nice if you could test this and give feedback. Works fine here with KWin.
> --- 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.
> Is anyone affected without using kwin? Yes, me! As I already wrote. I use fvwm2.
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(-)
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.
XDG_CURRENT_DESKTOP is only set in kde and gnome if I remember correct. In fvwm that variable is not set.
Please share environment. Is there any other variable to check for?
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"
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
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.
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.
> 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.
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
(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.
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
*** Bug 716230 has been marked as a duplicate of this bug. ***
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.
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
(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.
(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
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)
Landed here while investigating why smooth scrolling was still on notwithstanding all related options were disabled in `www-client/firefox-78.7.0` with Xfce/xfwm4. I have a laptop with touchpad, thus this is related to two-finger scrolling. $ echo $XDG_CURRENT_DESKTOP XFCE So, MOZ_USE_XINPUT2=0 fixes it ^^ Now I can re-enable FF's own smooth scrolling which works definitely better. I guess, XFCE should also be added to the "blacklist".
I can also confirm this problem on an ~amd64 machine.
I can confirm this on 2 different machines running fvwm and fvwm-crystal via startx. The only fix I could find is, as explained here by others, to put export GDK_CORE_DEVICE_EVENTS=1 in ~/.basshrc One system is amd64 with firefox 102.4.0esr, and the other one is ~amd64 with firefox 106.0.2 Both are using udev and libinput.
FWIW this is still an issue with: x11-wm/fvwm-2.7.0-r5 x11-themes/fvwm-crystal-3.7.5 www-client/firefox-129.0.2 I launch firefox via a wrapper in which I set MOZ_USE_XINPUT2=0 at some point and forgot all about it. But when launching without that wrapper, no scrollwheel. XDG_CURRENT_DESKTOP is not set (should fvwm be setting it?), closest is: XDG_SESSION_DESKTOP=fvwm-crystal Also, come to think of it I wonder if the underlying GTK3 issue is also what causes https://bugs.gentoo.org/show_bug.cgi?id=913387
