Marco should workaround invalid scroll event caused by mistake in X11/XInput 2.1 protocol design

Bug #2018333 reported by Mikko Rantalainen
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
marco (Ubuntu)
New
Undecided
Unassigned

Bug Description

#### Steps to reproduce the behaviour

Preparations: Open Firefox and Chrome windows in maximized state and switch between the windows using alt-tab while the mouse cursor is above the content area. Load a long web page to both browsers and scroll near the middle of document in both Firefox and Chrome.

1. Switch to Chrome using alt-tab.
2. Scroll downwards with a couple of clicks on mouse wheel.
3. Keep mouse cursor above the browser content area and press Alt+tab to switch to Firefox.
4. Scroll downwards a lot using mouse wheel.
5. Switch back to Chrome using alt+tab
6. Scroll downwards one click using mouse wheel.

#### Expected behaviour

Chrome should scroll the usual amount.

#### Actual behaviour

Chrome scrolls roughly the same amount Firefox was scrolled while Firefox was active!

#### Package version

$ apt policy mate-desktop marco
mate-desktop:
  Installed: 1.24.0-2
  Candidate: 1.24.0-2
  Version table:
 *** 1.24.0-2 500
        500 http://fi.archive.ubuntu.com/ubuntu focal/universe amd64 Packages
        100 /var/lib/dpkg/status
marco:
  Installed: 1.24.0-1ubuntu1
  Candidate: 1.24.0-1ubuntu1
  Version table:
 *** 1.24.0-1ubuntu1 500
        500 http://fi.archive.ubuntu.com/ubuntu focal/universe amd64 Packages
        100 /var/lib/dpkg/status

#### Linux Distribution

$ lsb_release -a
LSB Version: core-11.1.0ubuntu2-noarch:printing-11.1.0ubuntu2-noarch:security-11.1.0ubuntu2-noarch
Distributor ID: Ubuntu
Description: Ubuntu 20.04.6 LTS
Release: 20.04
Codename: focal

#### Additional information

The issue is caused by design problem in X11/XInput 2.1 protocol which causes first scroll event to have non-sensible scroll event data after switching windows using alt+tab. GTK has implemented workaround at the library level but it blindly assumes that the first event is broken. If first event gets ever changed to contain actual data, it's still ignored in the future. As such, implementing the workaround on window manager makes more sense because window manager is expected to keep track of window focus and it has the best information which event should be ignored or worked around.

I've reported this as Chromium bug at https://bugs.chromium.org/p/chromium/issues/detail?id=608246#c78 and https://bugs.chromium.org/p/chromium/issues/detail?id=608246#c68 but I now think that this workaround should be implemented in each window manager, if possible at all.

ProblemType: Bug
DistroRelease: Ubuntu 20.04
Package: marco 1.24.0-1ubuntu1
ProcVersionSignature: Ubuntu 5.15.0-69.76~20.04.1-lowlatency 5.15.87
Uname: Linux 5.15.0-69-lowlatency x86_64
NonfreeKernelModules: nvidia_modeset nvidia
ApportVersion: 2.20.11-0ubuntu27.26
Architecture: amd64
CasperMD5CheckResult: skip
CurrentDesktop: MATE
Date: Tue May 2 22:13:17 2023
EcryptfsInUse: Yes
InstallationDate: Installed on 2019-01-05 (1578 days ago)
InstallationMedia: Ubuntu 18.04.1 LTS "Bionic Beaver" - Release amd64 (20180725)
SourcePackage: marco
UpgradeStatus: Upgraded to focal on 2022-09-13 (231 days ago)
modified.conffile..etc.init.d.apport: [modified]
mtime.conffile..etc.init.d.apport: 2022-05-19T12:50:20.029158

Revision history for this message
Mikko Rantalainen (mira) wrote :
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.