Touchpad horizonal scroll gesture broken on GNOME 49

[KuxaBeast]

Describe the bug Since the last update to GNOME 49 (and the compatible PaperWM release), I am unable to use the 3-finger horizontal scroll touchpad gesture. Vertical 3-finger scroll is not affected.

To Reproduce Steps to reproduce the behavior:

1. Use the 3-finger horizontal touchpad gesture
2. The windows don't scroll horizontally, sometimes just for a split-second but overall unusable

Expected behavior The windows move horizontally just as on GNOME 48.

System information:

Distribution: openSUSE Tumbleweed
GNOME Shell: 49.0
Display server: Wayland
PaperWM version: 49.0.0
Enabled extensions:
- [email protected]
- steal-my-focus-window@steal-my-focus-window
- [email protected]
- [email protected]
- [email protected]

Additional context I figured out that if I patch the /usr/lib64/gnome-shell/libshell-17.so as described by this comment, the issue disappears and I can scroll normally again.

Hence I suspect some changes in gesture handling in GNOME 49 have been made and the workarounds in PaperWM will need to be amended accordingly, if possible.

[Fringale]

On my system (Aeon Desktop), whether or not this issue would appear after starting a session seemed decided by a coin flip. After some digging, I noticed that for me the difference comes down to this:

• If I go to the applications overview first thing after opening the session, before launching an application, then all is well and the issue does not occur.

• However, if the first application I launch is started directly from the dash (or panel, when using dash-to-panel), without going to the applications overview first, then:

  • The PaperWM three-finger horizontal swipe is broken
  • I get these errors in journalctl when swiping

gnome-shell[2197]: JS ERROR: TypeError: can't access property "children", this._pages[pageIndex] is undefined
getItemsAtPage@resource:///org/gnome/shell/ui/iconGrid.js:922:17
getItemsAtPage@resource:///org/gnome/shell/ui/iconGrid.js:1440:30
_translatePreviousPageIcons@resource:///org/gnome/shell/ui/appDisplay.js:314:34
_syncPageIndicators@resource:///org/gnome/shell/ui/appDisplay.js:387:14
goToPage@resource:///org/gnome/shell/ui/appDisplay.js:436:14
goToPage@resource:///org/gnome/shell/ui/appDisplay.js:1250:29
goToPage@resource:///org/gnome/shell/ui/appDisplay.js:1588:15
onComplete@resource:///org/gnome/shell/ui/appDisplay.js:731:36
_makeEaseCallback/<@resource:///org/gnome/shell/ui/environment.js:68:13
_easeActorProperty@resource:///org/gnome/shell/ui/environment.js:225:17
St.Adjustment.prototype.ease@resource:///org/gnome/shell/ui/environment.js:311:23
_swipeEnd@resource:///org/gnome/shell/ui/appDisplay.js:728:20
_endGesture@resource:///org/gnome/shell/ui/swipeTracker.js:651:14
_endTouchpadGesture@resource:///org/gnome/shell/ui/swipeTracker.js:672:14
_handleEvent@resource:///org/gnome/shell/ui/swipeTracker.js:196:18
@resource:///org/gnome/shell/ui/init.js:21:20

• And weirdly, the applications overview is empty (no application shown in the grid, only in the dash)

System information:

Distribution: Aeon
GNOME Shell: 49.0
Display server: Wayland
PaperWM version: 49.0.0
Enabled extensions:
- [email protected]

Would be interesting to know if those affected by the issue confirm this first application behaviour, and if they are openSUSE users like the reporter and me.

[cg505]

Probably related: https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2853 In particular, https://gitlab.gnome.org/GNOME/gnome-shell/-/commit/ca80a3cd5d0c6b20ff55b4dc8b1c345aed8a3263. This is pretty speculative, but it may be something like:

• without paperwm, the workspace SwipeTracker is enabled and captures swipe events on the desktop, and does not propagate them
• with paperwm, this SwipeTracker now has enabled=false, and so the swipe event is propagated down to the AppDisplay SwipeTracker, which can't handle it correctly since the app display view is not actually open
• before https://gitlab.gnome.org/GNOME/gnome-shell/-/commit/ca80a3cd5d0c6b20ff55b4dc8b1c345aed8a3263, this swipe event was filtered, but now it's not, causing a crash

Only took a cursory look so this could be wrong, but hopefully it's a starting point. Not sure what the appropriate fix would be.

[Fringale]

Great find @cg505!

I confirm that on my side the issue trigger boils down to the applications overview not having been opened prior to making a three-finger horizontal swipe on the desktop (with or without applications already opened).

[Vortex375]

I am on Arch Linux and I am always affected by this bug. But somehow my Gnome always starts into app overview directly after logging in. Then, it doesn't matter how I launch the first application, I am always affected by the issue. I have the Dash to Dock extension installed, if that's relevant.

This is the error that I am getting (same as seen previously):

gnome-shell[53386]: JS ERROR: TypeError: can't access property "children", this._pages[pageIndex] is undefined
    getItemsAtPage@resource:///org/gnome/shell/ui/iconGrid.js:922:17
    getItemsAtPage@resource:///org/gnome/shell/ui/iconGrid.js:1440:30
    _translatePreviousPageIcons@resource:///org/gnome/shell/ui/appDisplay.js:314:34
    _syncPageIndicators@resource:///org/gnome/shell/ui/appDisplay.js:387:14
    goToPage@resource:///org/gnome/shell/ui/appDisplay.js:436:14
    goToPage@resource:///org/gnome/shell/ui/appDisplay.js:1250:29
    goToPage@resource:///org/gnome/shell/ui/appDisplay.js:1588:15
    onComplete@resource:///org/gnome/shell/ui/appDisplay.js:731:36
    _makeEaseCallback/<@resource:///org/gnome/shell/ui/environment.js:68:13
    _easeActorProperty@resource:///org/gnome/shell/ui/environment.js:225:17
    St.Adjustment.prototype.ease@resource:///org/gnome/shell/ui/environment.js:311:23
    _swipeEnd@resource:///org/gnome/shell/ui/appDisplay.js:728:20
    _endGesture@resource:///org/gnome/shell/ui/swipeTracker.js:651:14
    _endTouchpadGesture@resource:///org/gnome/shell/ui/swipeTracker.js:672:14
    _handleEvent@resource:///org/gnome/shell/ui/swipeTracker.js:196:18
    @resource:///org/gnome/shell/ui/init.js:21:20

Software Information:

• OS Name: Arch Linux
• OS Build: (null)
• OS Type: 64-bit
• GNOME Version: 49
• Windowing System: Wayland
• Kernel Version: Linux 6.17.1-arch1-1

[cg505]

I confirm that on my side the issue trigger boils down to the applications overview not having been opened prior to making a three-finger horizontal swipe on the desktop (with or without applications already opened).

I cannot reproduce this.

I am on Arch Linux and I am always affected by this bug. But somehow my Gnome always starts into app overview directly after logging in. Then, it doesn't matter how I launch the first application, I am always affected by the issue. I have the Dash to Dock extension installed, if that's relevant.

This is the same for me. I am also on Arch.

[Fringale]

Just to be sure, here are the detailed steps that I do as a workaround (with all extensions disabled except PaperWM):

1. Log into Gnome session: it displays the Activities overview by default

2. Click on the application grid button in the Dash or Super+A to get to the Applications overview

3. Then whatever I do, the three-finger horizontal swipe will work as expected for the remainder of the session.

@cg505 @Vortex375 This does not work on your side?

---

And on the contrary to reproduce the issue 100%, I do the following:

1. Log into Gnome session (it displays the Activities overview by default)

2. Click to get to the desktop and do a three-finger horizontal swipe there

3. Swipe up twice or press Super twice or press Super+A to get to the Applications overview: the Applications overview is empty (no applications shown in the grid), and the three-finger horizontal swipe will be broken and generate journalctl errors as shown in above comments.

[LBY-L]

Fedora 43, exact same issue as well.

[ecelia]

I confirm this issue with Fedora 43.

[michalmielczynski]

confirming that on Fedora 43, Wayland, Thinkpad X1

[oreocapybara]

Someone fix this please

[Thesola10]

I understand the frustration but please do not clobber the discussion with "can confirm the bug." Issue discussions should be used to further investigation into the bug. In the mean time, a workaround for those affected is to open the Overview at any point after starting the session, even if the session started on the Overview.

[LBY-L]

The workaround suggested by @Fringale, doesn't work on my system, or at least completely, whenever I swipe to the left or right, the swipe doesn't seem to be enough to move the window, even though i use basically use all the space available on my trackpad, and when I swipe faster the gesture doesn't even recognize. But the desktop switcher works well.

I have both gestures assigned to the same number of fingers (3 fingers), but changing the number of fingers doesn't seem to make a change to the overall functionality.

System information (fastfetch): OS: Fedora Linux 43 (Workstation Edition) x86_64 Host: 20H1A073LM (ThinkPad E470) Kernel: Linux 6.17.5-300.fc43.x86_64 Display (BOE06B3): 1366x768 @ 60 Hz in 14" [Built-in] DE: GNOME 49.1 WM: Mutter (Wayland) CPU: Intel(R) Core(TM) i3-7100U (4) @ 2.40 GHz GPU: Intel HD Graphics 620 @ 1.00 GHz [Integrated]

[LBY-L]

I might add that, I have tested this with and without all of my extensions. Also the logs doesn't reveal nothing new.

[Vortex375]

The workaround doesn't work for me either. I do have the bug that the applications overview is empty. Following the steps in the above post makes the application overview work (applications are shown on the grid), but the swipe gesture is still not working for me.

[michalmielczynski]

Ok, simple workaround for Gnome 49 swipe issue. Since PaperWM provides Win+Left/Right hotkeys, we can use that to make swipe work again. Kind of. I can switch the windows again but it works exactly like a keyboard shortcut, on-off, you can not swipe back in the middle of swipe, unfortunately. Since someone smart finds out better way it is what it is. You can find it in my fork here: https://github.com/michalmielczynski/PaperWM

[LBY-L]

Ok, simple workaround for Gnome 49 swipe issue. Since PaperWM provides Win+Left/Right hotkeys, we can use that to make swipe work again. Kind of. I can switch the windows again but it works exactly like a keyboard shortcut, on-off, you can not swipe back in the middle of swipe, unfortunately. Since someone smart finds out better way it is what it is. You can find it in my fork here: https://github.com/michalmielczynski/PaperWM

I installed your fork, very good idea, but it seems that specific issue that causes that @Vortex375 and I cant get the workaround, is the same reason why it doesnt work, i think the gesture is like, inverted? whenever I swipe top to down from a corner (idk how to describe it), not from the left to the right as it supposed to, it seems to work (i mean that moves you to the right), but the way that I can do that is very unpredictable and awkward. So, that would be such a problem later.

[michalmielczynski]

I installed your fork, very good idea, but it seems that specific issue that causes that @Vortex375 and I cant get the workaround, is the same reason why it doesnt work, i think the gesture is like, inverted? whenever I swipe top to down from a corner (idk how to describe it), not from the left to the right as it supposed to, it seems to work (i mean that moves you to the right), but the way that I can do that is very unpredictable and awkward. So, that would be such a problem later.

Not sure why it does work that way on your side. I guess there's more variables that play role. On my end, swiping up/down/left/right work in predictable way. Anyways, it's just naive workaround, I treat it as temporary helper.