! Please note that this is a snapshot of our old Bugzilla server, which is read only since May 29, 2020. Please go to gitlab.xfce.org for our new server !
previous scroll remebered when switching window with alt+tab


Description troido 2020-04-17 16:55:21 CEST
Some applications apply the scroll events that were done before this application was focused when switching to them with alt+tab.
As far as I have noticed this only affects KDE applications (kate, konsole, krita).

Steps to reproduce:

1) Open kate (or konsole). Make sure that there is something to scroll both up and down so the difference is noticable.

2) Open any other application (firefox or thunar for example).

3) Scroll up a lot

4) Use alt+tab to go back to kate (or konsole)

5) Scroll down one step

Actual results:

Kate (or konsole) is scrolled up as much as you scrolled up in the previous window minus the single step you scrolled down (I never measured it exactly, but I think this is the scroll amount)

Expected results:

Kate (or konsole) is scrolled down one step

Krita shows similar behaviour to kate and konsole, but it only scrolls a single step.

I have tested this in Cinnamon's window manager for comparison (on the same OS) and this issue did not happen there. I just had the the expected behaviour.

I am using arch linux, with all relevant packages from the pacman repositories. I do not know when this bug was introduced, but it has there for at least several months.
Comment 1 Olivier Fourdan editbugs 2020-04-20 14:30:31 CEST
This is a bug on Qt.

Basically, with Xinput 2, the client needs to reset the valuator to 0 itself, and clients usually do so on FocusIn events.

Qt instead does that on EnterNotify, but ignores the EnterNotify events resulting from grabs first.

As xfwm4 needs to keep a grab on the pointer when cycling (for its own use), what Qt gets is an EnterNotify resulting from the ungrab and it discards it before resetting the valuator to 0, whcih explains why the Qt app gets a much bigger scrolling request than expected.

In qtbase/src/plugins/platforms/xcb/qxcbwindow.cpp:

2011 void QXcbWindow::handleEnterNotifyEvent(int event_x, int event_y, int root_x, int root_y,
2012                                         quint8 mode, quint8 detail, xcb_timestamp_t timestamp)
2013 {
2014     connection()->setTime(timestamp);
2016     const QPoint global = QPoint(root_x, root_y);
2018     if (ignoreEnterEvent(mode, detail, connection()) || connection()->mousePressWindow())
2019         return;
2020 #if QT_CONFIG(xcb_xinput)
2021     // Updates scroll valuators, as user might have done some scrolling outside our X client.
2022     connection()->xi2UpdateScrollingDevices();
2023 #endif
2025     const QPoint local(event_x, event_y);
2026     QWindowSystemInterface::handleEnterEvent(window(), local, global);
2027 }

Qt would need to reset the valuator to 0 regardless of the ignoreEnterEvent() for this to work.
Comment 2 Git Bot editbugs 2020-04-20 22:40:18 CEST
Olivier Fourdan referenced this bugreport in commit d2cf2e80ee0c997ae951282a611fadbd8c832094

cycle: Do not grab the pointer for alt-tab

Comment 3 Git Bot editbugs 2020-05-01 17:47:08 CEST
Olivier Fourdan referenced this bugreport in commit 18a9ad007e2cf9694eca8f5c759fd2eb154a9885

cycle: Do not grab the pointer for alt-tab

Comment 4 Olivier Fourdan editbugs 2020-05-01 18:08:18 CEST
The bug in in Qt, but xfwm4 now won't grab the keyboard on Alt-Tab to work around the issue in Qt.

Bug #16708

Reported by:
Reported on: 2020-04-17
Last modified on: 2020-05-01


Olivier Fourdan
CC List:
0 users




Additional information