SUMMARY When opening an unknown file, "Choose Application" portal window will be opened but it's not brought to the front. STEPS TO REPRODUCE 1. Open an unknown file in Dolphin 2. 3. OBSERVED RESULT Dolphin window is still the top window EXPECTED RESULT "Choose Application" is the top window SOFTWARE/OS VERSIONS Windows: macOS: Linux/KDE Plasma: (available in About System) KDE Plasma Version: 5.26.80 KDE Frameworks Version: 5.101 Qt Version: 5.15.7 ADDITIONAL INFORMATION
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
https://codereview.qt-project.org/c/qt/qtbase/+/448355
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