https://bugs.kde.org/show_bug.cgi?id=445462
Bug ID: 445462
Summary: Kwin grabs keyboard in doStartMoveResize() if it can't
grab pointer, resulting in freeze of entire session
Product: kwin
Version: 5.18.8
Platform: Debian stable
OS: Linux
Status: REPORTED
Severity: normal
Priority: NOR
Component: platform-x11-standalone
Assignee: kwin-bugs-n...@kde.org
Reporter: k...@kde.lka.org.lu
Target Milestone: ---
If some other application grabs the pointer when user wants to resize or move a
window, kwin can't get the pointer grab for itself, and "falls back" on
grabbing the keyboard instead. With the result that the entire X session
appears to freeze until user types ESCAPE key.
This race condition occurs roughly once every couple of days, and mostly
(only?) when attempting to move a firefox or Thunderbird window.
Currently, I'm running kwin 5.20.5, but the bug is much older than that, I
remember seeing this behavior since years already.
I've managed to get a stacktrace (using a preloaded object and the backtrace()
call, so please excuse the non-compliant formatting):
/usr/lib/x86_64-linux-gnu/libkwin.so.5(KWin::grabXKeyboard(unsigned
int)+0x143)[0x7f05fbd07793]
/usr/lib/x86_64-linux-gnu/libkwin.so.5(KWin::X11Client::doStartMoveResize()+0x3f2)[0x7f05fbd3aac2]
/usr/lib/x86_64-linux-gnu/libkwin.so.5(KWin::AbstractClient::startMoveResize()+0x155)[0x7f05fbbf0c35]
/usr/lib/x86_64-linux-gnu/libkwin.so.5(KWin::AbstractClient::performMouseCommand(KWin::Options::MouseCommand,
QPoint const&)+0x1c0)[0x7f05fbbf58b0]
/usr/lib/x86_64-linux-gnu/libkwin.so.5(KWin::X11Client::NETMoveResize(int, int,
NET::Direction)+0x166)[0x7f05fbc4ed76]
/usr/lib/x86_64-linux-gnu/libKF5WindowSystem.so.5(NETRootInfo::event(xcb_generic_event_t*,
QFlags<NET::Property>*, QFlags<NET::Property2>*)+0x30d)[0x7f05fb8e4fcd]
/usr/lib/x86_64-linux-gnu/libkwin.so.5(+0x1b1344)[0x7f05fbca6344]
/usr/lib/x86_64-linux-gnu/libkwin.so.5(KWin::Workspace::workspaceEvent(xcb_generic_event_t*)+0x107)[0x7f05fbc51b07]
/usr/lib/x86_64-linux-gnu/libQt5Core.so.5(QAbstractEventDispatcher::filterNativeEvent(QByteArray
const&, void*, long*)+0x87)[0x7f05fa8ba517]
/usr/lib/x86_64-linux-gnu/libQt5XcbQpa.so.5(QXcbConnection::handleXcbEvent(xcb_generic_event_t*)+0x61)[0x7f05f3dda7c1]
/usr/lib/x86_64-linux-gnu/libQt5XcbQpa.so.5(QXcbConnection::processXcbEvents(QFlags<QEventLoop::ProcessEventsFlag>)+0x76)[0x7f05f3ddbcd6]
/usr/lib/x86_64-linux-gnu/libQt5XcbQpa.so.5(+0x69b8c)[0x7f05f3dfeb8c]
/usr/lib/x86_64-linux-gnu/libQt5Core.so.5(QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>)+0x12b)[0x7f05fa8bb98b]
/usr/lib/x86_64-linux-gnu/libQt5Core.so.5(QCoreApplication::exec()+0x90)[0x7f05fa8c3c00]
/usr/bin/kwin_x11.wrapped(+0x7f59)[0x5619162a7f59]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xea)[0x7f05fa278d0a]
/usr/bin/kwin_x11.wrapped(_start+0x2a)[0x5619162a845a]
... and in X11Client::doStartMoveResize(), line 4730 of x11client.cpp, we do
indeed find the following code snippet, just after the attempt to grab the
pointer:
if (!pointerGrab.isNull() && pointerGrab->status ==
XCB_GRAB_STATUS_SUCCESS) {
has_grab = true;
}
This can't be helpful, as kwin needs a grab on the *pointer*, not on the
keyboard, in order to move the window. Even if it passes XCB_GRAB_MODE_SYNC
into pointer_mode, this just means that pointer events are "frozen" in the X
server, for later delivery to application, and not diverted to kwin (as would
happen with a true pointer grab).
IMHO, if pointer cannot be grabbed, it might be more appropriate to move on
directly to the next paragraph (line 4732), and just fail, rather than grab the
keyboard() which does not help:
if (!has_grab) { // at least one grab is necessary in order to be able to
finish move/resize
m_moveResizeGrabWindow.reset();
return false;
}
Or maybe a small delay followed with another pointer grab attempt. I suspect
what is happening here is that in response to a click in its title bar, firefox
or thunderbird grabs the pointer whatever strange reason but release it agan
almost immediately. If kwin "wins the race" (i.e. manages to grab the pointer
before firefox or thunderbird can) nothing bad happens, and window moves as
usual. If kwin "loses the race" by a wide margin, firefox or thunderbird will
already have released the pointer grab by the time kwin gets around to grabbing
it for itself, and nothing bad happens either. It's only when kwin "loses the
race" by a narrow margin that mayhem happens, and probably the reason why these
freezeups happen so rarely (but still often enough to be annoying)
--
You are receiving this mail because:
You are watching all bug changes.
