Bug 424584

I was about to file a bug report, and figured I'd better check to see if someone else has already. I'm affected by this too.

It looks like it was discussed here:
https://phabricator.kde.org/T13335

And it was thought to be okay to make the change because one KDE-specific bug from the past had been fixed.

The problem is that there are reasons that other desktop environments don't force this environment variable to be set by default, and for why Firefox does not use this behavior by default. This was not the best or brightest idea.

For what it's worth, I imagine this is probably more of an issue for those of us with more than one monitor, as it makes it more likely to have more than one app maximized at a time. That's the most likely scenario in which you'd want to be able to scroll a web page while the browser is not in focus.

Since this affects more than one user, I suppose it might be proper to change the status to 'confirmed', but I'm basically a nobody here - and I'm surprised the drop-down for changing the status isn't grayed out or something. I'll leave that alone until a maintainer or someone with more knowledge comes around.

Hmm, this was supposed to be non-destructive with KWin from Plasma 5.19.3, which added a change to fix the bugs you're seeing. :/

Folks who are affected: can you describe the contidions under which you're affected? Is it always? only when using more than one monitor? When another window is maximized? Etc.

(In reply to Nate Graham from comment #2)
> Hmm, this was supposed to be non-destructive with KWin from Plasma 5.19.3,
> which added a change to fix the bugs you're seeing. :/
> 
> Folks who are affected: can you describe the contidions under which you're
> affected? Is it always? only when using more than one monitor? When another
> window is maximized? Etc.

I am using a single monitor. The issue is present when:
- Firefox is in the background, both maximised or not, and I have another window in the foreground (e.g. Kate);
- Firefox is in the foreground, another window comes in front of it (e.g. I open Kate) and this new window is then minimised;
- I switch to another window, both using alt+tab or the taskbar/Dock (I use Latte), and then switch back. 
In all cases I have to minimise Firefox and restore it for scrolling to come back. It has to be noted that scrolling is broken not just when it is in the background, but in the foreground as well.

(In reply to Colin Griffith from comment #1)
> For what it's worth, I imagine this is probably more of an issue for those
> of us with more than one monitor, as it makes it more likely to have more
> than one app maximized at a time. That's the most likely scenario in which
> you'd want to be able to scroll a web page while the browser is not in focus.

This issue is also impacting those who use side-by-side windows, with Firefox on one half of the screen and another window in the other. This is one of the most common use cases for me. I also tend to use Yakuake following instructions from a web page, which requires scroll behaviour to work. I am sure there are other use cases as well.

What you're describing perfectly matches the symptoms of Bug 394772. It's like the fix is not present on your machine. I also had those exact symptoms before it was fixed, but now it's fixed for me. :/

Did that get reverted in the stable branch or in Neon or something? It's definitely fixed for me with git master.

(In reply to Nate Graham from comment #4)
> What you're describing perfectly matches the symptoms of Bug 394772. It's
> like the fix is not present on your machine. I also had those exact symptoms
> before it was fixed, but now it's fixed for me. :/
> 
> Did that get reverted in the stable branch or in Neon or something? It's
> definitely fixed for me with git master.

To be clear, you can have Firefox and Kate open, and be typing letters in Kate while the mouse hovers over Firefox, and scroll Firefox while Kate still accepts all keyboard inputs from you typing?

I don't know if you might be using 'focus follows mouse' or something like that, which might mess with the behavior being described.

(In reply to Colin Griffith from comment #5)
> (In reply to Nate Graham from comment #4)
> > What you're describing perfectly matches the symptoms of Bug 394772. It's
> > like the fix is not present on your machine. I also had those exact symptoms
> > before it was fixed, but now it's fixed for me. :/
> > 
> > Did that get reverted in the stable branch or in Neon or something? It's
> > definitely fixed for me with git master.
> 
> To be clear, you can have Firefox and Kate open, and be typing letters in
> Kate while the mouse hovers over Firefox, and scroll Firefox while Kate
> still accepts all keyboard inputs from you typing?
> 
> I don't know if you might be using 'focus follows mouse' or something like
> that, which might mess with the behavior being described.

I just checked to make sure: settings report "click to focus". Other than that, it's as you described: you have Firefox open, but not in focus, with Kate in the foreground and in focus; while you type in Kate, you can't scroll Firefox.

(In reply to Colin Griffith from comment #5)
> To be clear, you can have Firefox and Kate open, and be typing letters in
> Kate while the mouse hovers over Firefox, and scroll Firefox while Kate
> still accepts all keyboard inputs from you typing?
Yes.

> I don't know if you might be using 'focus follows mouse' or something like
> that, which might mess with the behavior being described.
No.

I am starting to wonder if this got reverted in 5.19 or in Neon or is broken there by something else...

Are either of you able to test with current git master or Neon Unstable with MOZ_USE_XINPUT2=1 set and report back?

(In reply to Nate Graham from comment #8)
> I am starting to wonder if this got reverted in 5.19 or in Neon or is broken
> there by something else...
> 
> Are either of you able to test with current git master or Neon Unstable with
> MOZ_USE_XINPUT2=1 set and report back?

Well, this is just the right timing! I have to test a server with Proxmox so I'll spin up a VM with Neon Unstable and report back.

I tested this using Neon Unstable and I can confirm it works there.

Phew, I'm not crazy. So then one of the following is happening:
- The fix is not actually in Plasma 5.19.3
- The fix is in Plasma 5.19.3 but got reverted in Neon or never made it in
- The fix is in Neon's Plasma 5.19.3 but it is not working

5.19.3 rollout was incomplete.

kwin-x11:
  Installed: (none)
  Candidate: 4:5.19.2-0xneon+18.04+bionic+build75

Looks like the following packages are still 5.19.2, at least on my end:

kwin-common
kwin-data
kwin-dev
kwin-wayland
kwin-wayland-backend-drm
kwin-x11
libkwin4-effect-builtins1
libkwineffects12
libkwinglutils12
libkwinxrenderutils12
plasma-sdk
plasma-thunderbolt

There are also several I don't have installed, namely all the Wayland backends and various '-dbgsym' packages.

https://build.neon.kde.org/view/mgmt/job/mgmt_version_list_bionic_user/383/testReport/

03:17:10 Version for kdenlive found '20.04.2' but expected '20.04.3'!
03:17:10 The source kdeconnect-kde appears not available in our repo!
03:17:10 Looks like this needs a map (double check this!!!):
03:17:10   'kdeconnect' => 'kdeconnect-kde',
03:17:10 Version for elisa found '20.04.2' but expected '20.04.3'!
03:17:10 Version for kcmutils found '5.71.0' but expected '5.72.0'!
03:17:10 Version for kwin found '5.19.2' but expected '5.19.3'!
03:17:10 Version for plasma-phone-components found '5.18.5' but expected '5.19.3'!
03:17:10 Version for plasma-thunderbolt found '5.19.2' but expected '5.19.3'!
03:17:10 Version for plasma-sdk found '5.19.2' but expected '5.19.3'!

Just saw KWin update, and I uncommented that line in /etc/xdg/plasma-workspace/env/neon_moz_use_xinput.sh. Scrolling in unfocused Firefox works again :D

I had it since yesterday. It was quite random.
5.19.3. I updated. Kwin was part of the update. It looks fixed. I'll report if I find it isn't.

Ok, a bug that is present in Chrome but used to be absent from Firefox is now showing up in Firefox (and slightly worse) ever since this was implemented. It might be related, but I don't know as I can't test in any other desktop environments.

In Chrome, if you are in another window and then click back onto the Chrome window, so Chrome is now definitely the active window... The first scroll event sent to Chrome is ignored.

Now in Firefox, the first scroll event after clicking is ignored. I don't have to make a different window active to observe this effect.

For now, I've commented out that line again.

As far as I am aware, the MOZ_USE_XINPUT2 environment variable is only consumed by Firefox. I don't know that it affects Chrome/Chromium in any way. If it does, I'll be surprised.

But regardless, what you are describing sounds a whole lot like the original bug itself (Bug 394772) that is now fixed in KWin 5.19.3. Are you sure you have KWin 5.19.3 or later?

(In reply to Colin Griffith from comment #17)
> Now in Firefox, the first scroll event after clicking is ignored. I don't
> have to make a different window active to observe this effect.

You're describing a well know bug in the xi2 protocol. When an application receives a XI_Enter event, it needs to reset scroll valuators. From the user's perspective, it can be seen as the first scroll being ignored.

a well known*

this one also breaks gestures. with MOZ_USE_XINPUT2=0 scrollbar and gestures seem to work again for me.

What do you mean by "Gestures"? Touchscreen gestures? Touchpad gestures? Mouse gestures? Which ones?

(In reply to Nate Graham from comment #22)
> What do you mean by "Gestures"? Touchscreen gestures? Touchpad gestures?
> Mouse gestures? Which ones?

sorry, my bad. meant mouse gestures.

Mouse gestures using KDE's KHotkeys?

(In reply to Nate Graham from comment #24)
> Mouse gestures using KDE's KHotkeys?

yes.