Firefox: scrolling is not a constant speed with env var MOZ_USE_XINPUT2=1

[tom-james-watson]

trafficstars

I've recently switched to Pop!_OS and I have reencountered a bug that I have seen several times in the past on other linux distributions / firefox versions.

When scrolling with j/k or d/u, after holding the key down for what feels like the system key-repeat timeout, it starts scrolling multiple times faster than it should. Before key-repeat kicks in, it scrolls at the expected speed. It seems like once the system repeats the key, vimium applies the scroll speed more than once. For j/k it ends up moving about twice as fast as expected and for d/u multiple times faster than expected.

I love your extension so much that I've actually had to switch to Chrome rather than keep using Firefox without proper scrolling. Let me know if there's anything I can try or any diagnostics I can provide. Thanks!

Firefox: 69.0 OS: Pop!_OS 19.04 Kernel: 5.0.0-27-generic

[gdh1995]

I think this is because Firefox could not learn those keys are "repeated", so please open https://gdh1995.github.io/vimium-c/keyboard-test.html and do some tests:

• open this page on Firefox and Pop!_OS
• ~~press~~ ~~Shift~~ press J and hold on (not release the key)
• see what the page would show
• open Chrome and do similar tests.

Please provide some snapshots. The expected result is ~~** keydown.repeat ShiftLeft Shift~~ ** keydown.repeat KeyJ j, while if no ".repeat", then it would mean Firefox is not fully compatible with the system.

[tom-james-watson]

For shift I just get the following on firefox and chrome:

1 | keydown | ShiftLeft | Shift |  
2 | keyup | ShiftLeft | Shift

However for j on chrome I get:

1 | keydown | KeyJ | j |  
2 | keypress | KeyJ | j |  
3 | keydown.repeat | KeyJ | j |  
4 | keypress.repeat | KeyJ | j |  
5 | keydown.repeat | KeyJ | j |  
6 | keypress.repeat | KeyJ | j |  
7 | keydown.repeat | KeyJ | j |  
8 | keypress.repeat | KeyJ | j |  
9 | keydown.repeat | KeyJ | j |  
10 | keypress.repeat | KeyJ | j |  
11 | keydown.repeat | KeyJ | j |  
12 | keypress.repeat | KeyJ | j |  
13 | keyup | KeyJ | j

whereas j on firefox is:

1 | keydown | KeyJ | j |  
2 | keypress | KeyJ | j |  
3 | keydown | KeyJ | j |  
4 | keypress | KeyJ | j |  
5 | keydown | KeyJ | j |  
6 | keypress | KeyJ | j |  
7 | keydown | KeyJ | j |  
8 | keypress | KeyJ | j |  
9 | keydown | KeyJ | j |  
10 | keypress | KeyJ | j |  
11 | keydown | KeyJ | j |  
12 | keypress | KeyJ | j

So yeah, looks like you're right. I have an ubuntu machine I can try this on later, too. I'm pretty sure I've seen it on plain ubuntu too.

[benide]

I have the same issue with the same diagnostics. Do either of you have any ideas about where to start looking to make firefox compatible on my system? For the time being, I've also switched to chromium just so I can comfortably use vimium :)

[gdh1995]

@benide What's your operating system?

[benide]

Fedora 31. It also occured in Fedora 30 after an update a week or two ago (before the switch to 31), but I'm not super good about updating regularly so it's hard to say exactly when that update existed. I'm using firefox 70.0.

I'll see if I can figure out how dnf history works well enough to give you a better idea of the change that occured when it broke, but I'm not 100% confident in my abilities here haha.

[benide]

~~Ok, so I tried all the version of Firefox that I went through in recent upgrades by downloading the .tar directly, and everything works perfectly with all versions. I ruled out any interacting addons by just disabling everything, so I guess it has something to do with the build of firefox shipping with Fedora.~~

UPDATE: After syncing on the downloaded (and temporarily working) firefox, the problem came back. It doesn't seem to be an addon, but it's definitely one of my settings. I'll let you know when I figure it out.

[benide]

So I've determined that my problem is actually two separate problems. The problem that @tom-james-watson was refering to always occurs with the Fedora repo build of Firefox, and is fixed by using the build directly from the Firefox website. This will probably fix it for @tom-james-watson as well, and doesn't really sound like a problem with vimium to me.

My other problem doesn't really belong in this issue. If I can figure out enough info to make it worth looking at (and it ends up being a vimium problem), I'll open a new issue.

[tom-james-watson]

I just tried downloading Firefox directly from their website and I get the same issue. This was before I had enabled sync or anything so it's not a addon related issue.

Also, I don't see this issue on another computer of mine on Ubuntu 19.10 and I also don't see this on a fresh VM installation of Pop!_OS 19.10. Seems no closer to narrowing down what the cause is and I don't really want to reinstall my OS as this is my main workstation.

[gdh1995]

@tom-james-watson @benide It seems that this bug occurs because Firefox runs on "Wayland" . So you have to install a "standard" Firefox to run on X11.

As said in [1], Fedora 31 switches to a version of Firefox which uses Wayland natively (without the XWayland [2] shim any more), so I tested behaviors with / without Wayland by export MOZ_ENABLE_WAYLAND=1 ~~and 0~~ [3], and the below are my results:

• On Wayland

• On X11

Therefore, I think I've found the root cause: Firefox's support for Wayland is not so good.

A work-around is to use official versions of Firefox and avoid export MOZ_ENABLE_WAYLAND=1 (you may add a script to ~~make it always 0, just like [3]~~ clear the environment before running Firefox).

Added: I've added a warning to the bottom of https://github.com/philc/vimium/wiki/FAQ.

Update

~~After testing I find export MOZ_ENABLE_WAYLAND=0 works just like export MOZ_ENABLE_WAYLAND=1, so I modify the work-around.~~

MOZ_USE_XINPUT2 will also affect this.

Reference

[1] https://fedoramagazine.org/firefox-tips-for-fedora-31/ [2] https://askubuntu.com/questions/980357/how-to-run-xorg-programs-on-wayland [3] https://www.reddit.com/r/firefox/comments/c8itj2/enabling_wayland_on_linux/

[tom-james-watson]

This may be the case for some users, but I'm on an X11-only session (I'm running nvidia drivers so no option of running wayland for the moment even if I wanted to). So, my Firefox is always running in x11 mode and this happens regardless.

[gdh1995]

@tom-james-watson Firefox supports log files, and you may run (in terminal) MOZ_LOG=KeymapWrapperWidgets:3 MOZ_LOG_FILE=/tmp/moz_log.txt firefox to notify Firefox to write logs about keyboard into /tmp/moz_log.txt*. And then please upload it here, or for protecting your privacy, send it to my email ([email protected]) - I promise that I won't share your log files with other people or send it to others machines. Instead, I'll delete it at once I find out the cause.

Reference

[1] environment variables for logging: https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Gecko_Logging [2] the code whch should have run but in fact didn't: https://dxr.mozilla.org/mozilla-central/source/widget/gtk/nsGtkKeyUtils.cpp#820 .

[benide]

I'm also running X11. Changing MOZ_ENABLE_WAYLAND had no effect on behavior (the Fedora build didn't work properly either way, the Mozilla build did work properly both ways). I've emailed you the logs.

edit: I should add that I'm also using nvidia drivers.

[gdh1995]

Well, after hard searching, I failed to found the root cause. As far as I've found, the potential causes are:

• XGetKeyboardControl returns a state of global_auto_repeat = false
  • in https://dxr.mozilla.org/mozilla-central/source/widget/gtk/nsGtkKeyUtils.cpp#434
  • then no events can be treated as "repeatable" ones
  • so IsAutoRepeatableKey in https://dxr.mozilla.org/mozilla-central/source/widget/gtk/nsGtkKeyUtils.cpp#791 always returns false
• or, gdk_window_add_filter fails in its inner
  • in https://dxr.mozilla.org/mozilla-central/source/widget/gtk/nsGtkKeyUtils.cpp#372
  • then no events will be passed to FilterEvents
  • and then no “repeat” status will be toggled

Because of lacking logs inside the code block in line 791, I can not tell which one should be to blame.

Maybe a report in bugzilla is needed.

BTW, the code confirms my last guess that Firefox lacks supports for "repeat" status when using Wayland - currently the support requires InitXKBExtension.

Updates

• I've filed https://bugzilla.mozilla.org/show_bug.cgi?id=1594003 .

[gdh1995]

@benide Sorry but I have a question: in Fedora 31, the pre-installed Firefox seems to have only Wayland support, so could you provide a snapshot of about:support on Firefox to convince me that it's using X11 ? Have you installed firefox-x11.x86_64 using yum?

Added: I find that the firefox-x11 packages only does this:

export MOZ_DISABLE_WAYLAND=1
exec /usr/bin/firefox "$@"

And MOZ_DISABLE_WAYLAND seems from a customized version of Firefox (by Fedora) - https://dxr.mozilla.org/mozilla-central/search?q=MOZ_DISABLE_WAYLAND&redirect=false is empty.

Update 2: I tested MOZ_DISABLE_WAYLAND=1: it made Firefox (Fedora) use X11 but there're still no FilterEvents log items, and keydown events still have repeat=false.

[tom-james-watson]

Hey - just sent you the logs from a fresh firefox install for you to take a look at. Thanks!

[benide]

I was just using firefox.x86_64, the reason I say I'm running X11 is because I'm using the Cinnamon DE which doesn't do Wayland. Diffing between about:support for the Fedora and Mozilla builds doesn't look very interesting, but I've emailed them to you.

[gdh1995]

@tom-james-watson How did you get your Firefox 69? I find the Fedora version has something different from the official one, which causes this bug. So I wonder whether the official ones can work on your Pop!_OS . You may download official Firefox from https://ftp.mozilla.org/pub/firefox/releases/ .

[tom-james-watson]

The logs I sent you were from directly running the binary downloaded directly from the firefox website. They looked the same as what was produced from my normal firefox install, which is installed from the ubuntu 19.10 repositories.

[gdh1995]

Hello. I find MOZ_USE_XINPUT2 is a magic environment variable.

In Fedora, /usr/bin/firefox is a shell script and it forces MOZ_USE_XINPUT2=1, and then yum-installed Firefox always loses .repeat status. And, MOZ_USE_XINPUT2=0 /usr/lib64/firefox/firefox works well.

MOZ_USE_XINPUT2 is default to 0, so Firefox from the official website also works.

The source code is https://dxr.mozilla.org/mozilla-central/source/toolkit/xre/nsAppRunner.cpp#3750 .

[tom-james-watson]

Ohh damn you're right! You have just reminded me that I had followed https://old.reddit.com/r/linux/comments/72mfv8/, with the intention of improving touchpad scrolling.

Removing that file and logging back in has fixed the problem. So yeah, looks like that was the problem all along!

[tom-james-watson]

And thank you so much for all your help @gdh1995 - very much appreciated! Hopefully this will help resolve the issue for some others too.

[benide]

Awesome, thanks @gdh1995!

[gdh1995]

OKay, then we may close this issue ^_^

[Invertisment]

I've recently upgraded my Firefox to 105.0.2 and all the scrolls with JKDU became non-constant-speed (they scroll normally for 1-2s and then speed increases). These are the screenshots from your webpage (in chrome and in firefox):

Firefox 105.0.2 (64-bit):

Chromium Version 106.0.5249.103 (Official Build) Arch Linux (64-bit):

How can I make it behave as before the upgrade? It wasn't speeding up before.

[gdh1995]

The snapshot shows Firefox doesn't expose the state of "a key is being pressed" (no .repeat). So, as said in https://github.com/philc/vimium/issues/3386#issuecomment-549318796 , please try removing export MOZ_ENABLE_WAYLAND=1 firstly.

Added: I reproduced https://github.com/philc/vimium/issues/3386#issuecomment-549318796 on my Ubuntu 18.04.2 LTS (WSL2) + Firefox 105.0+build2-0ubuntu0.18.04.1 .

[Invertisment]

The problem is that I think that I shouldn't have this variable set because I'm on Xorg. So no Wayland is running. I remember editing some kind of config file where I could put env variables for Firefox but I don't remember where it is. But I don't think that I had added this variable there.

I'll try to test it later. Initial test with already running firefox and running of this command MOZ_ENABLE_WAYLAND=0 firefox didn't have different results.

[gdh1995]

um, please try: close all firefox processes, export env, exec the firefox ELF file directly.

[Invertisment]

I upgraded my Firefox to the latest version. Currently it's 105.0.3 (64-bit).

This command gives no output: printenv | grep WAYLAND (i.e. wayland variable is not set). If I look for MOZ I get this:

printenv | grep MOZ
MOZ_USE_XINPUT2=1

I use Xorg, the version is X.Org X Server 1.21.1.4.

I stopped my firefox (and I checked that it doesn't appear in pgrep firefox). Then I started firefox from command line by typing firefox. That executable calls the actual executable directly (which is located in /usr/lib/firefox/firefox).

I also recently upgraded my kernel from 5.19 to 6.0.0-1 (the behavior is the same in both kernels). I use Manjaro Linux.

The output in Firefox is still the same:

[gdh1995]

Um, could you view about:support on Firefox, and then search for Window Protocol? I guess Firefox just enabled a new logic to enable wayland by default.

On my Firefox 105 for Ubuntu 18.04, Window Protocol is "xwayland" when without MOZ_ENABLE_WAYLAND=1 (or with MOZ_ENABLE_WAYLAND=0), and with it it's "wayland".

The built-in page of Firefox will also list all received environment variables, so if you run MOZ_ENABLE_WAYLAND=0 firefox from a shell, there will show it.

I've searched in about:config but there seems no flag to toggle a whole wayland feature, so if the above test shows xwayland I'll have to say I have no idea.

[gdh1995]

Update: @Invertisment Oh I just noticed MOZ_USE_XINPUT2=1 will also prevent the keyboard repeating status. And MOZ_USE_XINPUT2=0 will solve this.

Update 2: see https://github.com/philc/vimium/issues/3386#issuecomment-553327296