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.
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: ```c 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); 2015 2016 const QPoint global = QPoint(root_x, root_y); 2017 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 2024 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.
Olivier Fourdan referenced this bugreport in commit d2cf2e80ee0c997ae951282a611fadbd8c832094 cycle: Do not grab the pointer for alt-tab https://git.xfce.org/xfce/xfwm4/commit?id=d2cf2e80ee0c997ae951282a611fadbd8c832094
Olivier Fourdan referenced this bugreport in commit 18a9ad007e2cf9694eca8f5c759fd2eb154a9885 cycle: Do not grab the pointer for alt-tab https://gitlab.xfce.org/xfce/xfwm4/commit/18a9ad007e2cf9694eca8f5c759fd2eb154a9885
The bug in in Qt, but xfwm4 now won't grab the keyboard on Alt-Tab to work around the issue in Qt.