Currently, on Wayland window activates any newly mapped toplevel, since apps typically only use XDG activation (which has logic for preventing stealing input, among other things) for handover but not on initial window show. While this makes the system behave as expected in many cases (app gets launched, window gets focus) it can also cause Windows to steal focus from the user while typing or cause unexpected windows (such as the desktop window when plasma starts, cf. !4349 ) to get focus. See also https://bugs.kde.org/show_bug.cgi?id=495862. This issue collects places where focus breaks if KWin never automatically focusses any windows, so the issues can be fixed and eventually KWin gets full control over when to activate windows. # Issues - [x] For real-world testing, an “xdg activation only” mode in KWin shall be added where windows will never automatically get focussed in `Workspace::addWaylandWindow`: https://invent.kde.org/plasma/kwin/-/merge_requests/4659 * Most logically, this can be tied to “focus stealing prevention”, e.g. setting it to “Extreme” (4) - [x] Patch `QWaylandWindow` to `requestActivate` on window show (unless `Qt::WA_ShowWithoutActivating` is set): https://codereview.qt-project.org/c/qt/qtwayland/+/519444 * Many platforms do this implicitly or have heuristics on their own, but on Wayland we have to request activation ourselves. - [x] KWin refuses the aforementioned activation in `XdgToplevelWindow::takeFocus()` because `!readyForPainting()`. The activation token situation all works, though, otherwise we wouldn’t even get to `takeFocus()`. - [x] KRunner thinks it’s activated, blinking cursor and all, even though it didn’t actually get activated: https://invent.kde.org/plasma/layer-shell-qt/-/merge_requests/84 and https://invent.kde.org/plasma/layer-shell-qt/-/merge_requests/82 * KRunner activates successfully through global shortcut with the above QtWayland patch, though, so not that big of a deal. - [ ] No way to launch an application with a token from terminal - [ ] GTK 4 apps try to activate themselves on launch (only tested the Calculator) but KWin refuses to grant a token (has a workaround) * Shouldn’t they be using the token they got on launch from `XDG_ACTIVATION_TOKEN`? * Qt also mentions a GTK “quirk” where apps need to request xdg activation regardless?! ``` // At least GNOME requires to request the token in order to get the` // focus stealing prevention indication, so requestXdgActivationToken call // is still necessary in that case. ``` - [x] Closing a window that’s not active should allow the app to bring forward its “Save?” prompt: https://invent.kde.org/plasma/kwin/-/merge_requests/8402 - [x] Chrome requests a token but doesn’t use it when creating a new window (Ctrl+N): https://issues.chromium.org/issues/435251395 (has a workaround) - [x] Activation from context menus (e.g. right-click a file, Open With) doesn’t properly work as the menu is gone by the time the activation happens * [ ] GTK 3 / Qt 5.15 = ¯\\_(ツ)\_/¯ # What works then Assuming the aforementioned QtWayland patch and KWin fixed, windows correctly get focus when: - [x] Opening new windows from themselves in response to user interaction (e.g. properties dialog, save prompts, even “open new window”) * Opening plasmoid popups from `plasmawindowed` works, too, didn’t test yet how it behaves with a real panel (which doesn’t accept focus) - [x] Launch application through KRunner/Kickoff * Systemsettings seems to work even without the Qt change, perhaps because of DBus-activation / `KDBusService` - [x] Launch application through global shortcut - [x] Context menus, they aren’t toplevels - [x] Chrome properly passes focus to existing browser windows upon activating a link # Notes * Stacking order is entirely unaffected, so a new window can still open and completely cover the window that currently has the focus