Bug 445462

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)