| Summary: | On X11, portal-based "Choose Application" window is not brought to the front automatically when Focus stealing prevention is enabled due to a questionable QtXcb behavior | ||
|---|---|---|---|
| Product: | [Plasma] xdg-desktop-portal-kde | Reporter: | Fushan Wen <qydwhotmail> |
| Component: | general | Assignee: | Plasma Bugs List <plasma-bugs-null> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | aleixpol, jgrulich, nate, rsi.dev17, s, sitter |
| Priority: | NOR | Keywords: | regression, usability |
| Version First Reported In: | git-master | ||
| Target Milestone: | --- | ||
| Platform: | Other | ||
| OS: | Linux | ||
| Latest Commit: | https://invent.kde.org/plasma/plasma-workspace/commit/22c7bc9f6bbb8363c3cb339728ab61bbf790661b | Version Fixed/Implemented In: | 5.27 |
| Sentry Crash Report: | |||
|
Description
Fushan Wen
2022-11-20 14:37:12 UTC
X11 or Wayland? And in which app(s)? I cannot reproduce on X11 when I invoke the dialog from Plasma (folder View) or Dolphin. X11 in Dolphin and weird enough I can reproduce the bug with a new user Does it happen on Wayland? (In reply to Nate Graham from comment #3) > Does it happen on Wayland? No, I think X11 is doomed nowadays. Well, it's still the default session type for now and for probably at least the next year and a half, so we ought to fix it. I can't reproduce this bug, I am using x11 session with dolphin Version 22.08.3, can someone confirm that its been fixed A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-integration/-/merge_requests/63 Git commit 2b3bfe9c09edd25dc3d467616001ce0f5c528e05 by Harald Sitter. Committed on 12/12/2022 at 10:53. Pushed by sitter into branch 'master'. correctly use x11 wid as hex, not decimal as per the docs: > Under X11, the "parent_window" argument should have the form "x11:XID", where XID is the XID of the application window in hexadecimal notation. maybe helps with M +1 -1 src/platformtheme/kdeplatformtheme.cpp https://invent.kde.org/plasma/plasma-integration/commit/2b3bfe9c09edd25dc3d467616001ce0f5c528e05 A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/2434 So Fushan Wen is proposing to fix it by no longer checking whether a window is transient before setting WM_TRANSIENT_FOR; but why is this "Choose Application" window not transient according to the definition in qxcbwindow.cpp?
// Returns \c true if we should set WM_TRANSIENT_FOR on \a w
static inline bool isTransient(const QWindow *w)
{
return w->type() == Qt::Dialog
|| w->type() == Qt::Sheet
|| w->type() == Qt::Tool
|| w->type() == Qt::SplashScreen
|| w->type() == Qt::ToolTip
|| w->type() == Qt::Drawer
|| w->type() == Qt::Popup;
}
It was made not a dialog because doing so hid its window decoration close button on X11 (but not Wayland, interestingly). This may be a KWin or Qt bug and ideally we would investigate and fix that, so the window can be a dialog again without regressing things for people on X11. Git commit 22c7bc9f6bbb8363c3cb339728ab61bbf790661b by Fushan Wen. Committed on 02/01/2023 at 00:40. Pushed by fusionfuture into branch 'master'. SystemDialog: use `Qt.WindowCloseButtonHint` flag to add close button to decoration According to the source code in qxcbwindow.cpp, WM_TRANSIENT_FOR will only be set when a window belongs to certain types. When focus stealing prevention is enabled, KWin tries to match transient window, and it will block window activation when WM_TRANSIENT_FOR is not set. See also https://codereview.qt-project.org/c/qt/qtbase/+/448355 FIXED-IN: 5.27 M +1 -1 lookandfeel/org.kde.breeze/contents/systemdialog/SystemDialog.qml https://invent.kde.org/plasma/plasma-workspace/commit/22c7bc9f6bbb8363c3cb339728ab61bbf790661b |