| Summary: | Portal file picker not modal with its parent window, which can cause various UX issues | ||
|---|---|---|---|
| Product: | [Plasma] xdg-desktop-portal-kde | Reporter: | Fernando M. Muniz <fernandommuniz> |
| Component: | general | Assignee: | Plasma Bugs List <plasma-bugs> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | 4wy78uwh, aleixpol, bizyaev, hartmann.christian, kde, kde, krammer, nate, strong.drum0546 |
| Priority: | NOR | Keywords: | usability |
| Version First Reported In: | 6.3.3 | ||
| Target Milestone: | --- | ||
| Platform: | Arch Linux | ||
| OS: | Linux | ||
| Latest Commit: | https://invent.kde.org/frameworks/kwindowsystem/-/commit/daa3cda4d4831b692f504f98aa6eeddabceb64a1 | Version Fixed In: | Frameworks 6.14 |
| Sentry Crash Report: | |||
| Attachments: | File picker is recognized (by not opening another one), but doesn't go back into focus. | ||
To expand on the "PS:" part, I think that the file picker should tell in the window's title bar what site/app it's going to send the files to. This addition could cause the File Picker's security be increased. "File Upload - Summoned by *URL address* This probably deviates too much from the original issue, so please tell me if I should file another bug for it. I've noticed that the file picker is limited to one window per app. I've asked a friend, and apparently MS Windows' solution is to make the main app non-interactable until a file is picked. (terrible solution) I think this would be the perfect file picker: 1- Limited to only one instance system-wide; it will use tabs instead. 2- Internet browsers will now be able to summon multiple file picker tabs, but only if they are summoned by different websites. 3- The tabs will display which url and/or app that summoned it, for security reasons. 4- Trying to summon the file picker when a tab for it is already open will now focus on the existing file picker and switch to the existing tab. Ignore comment 3. It became Bug 494882 *** Bug 502311 has been marked as a duplicate of this bug. *** From https://bugs.kde.org/show_bug.cgi?id=502311 the positioning relative to the parent is reported to work on kwin_wayland Maybe the modality issue works there as well? same issue with: Changing the properties of a file type in Dolphin. "Edit File Type" dialog opens in top left corner of a different screen than the first opened "Properties" dialog. changed back(?) to kwin Product. Edit File Type has nothing to do with the file picker. This would be solved by [1], so please file a separate issue for that. [1] https://invent.kde.org/frameworks/kio/-/merge_requests/1528 A possibly relevant merge request was started @ https://invent.kde.org/frameworks/kwindowsystem/-/merge_requests/176 Git commit daa3cda4d4831b692f504f98aa6eeddabceb64a1 by Kai Uwe Broulik. Committed on 16/04/2025 at 07:00. Pushed by broulik into branch 'master'. Wayland: Set XDG dialog modal in setMainWindow when applicable Before Qt 6.10, Qt's built-in XDG Dialog support only sets modal when it has an in-process transient parent. It wouldn't know that we'll be setting a parent through XDG Foreign afterwards. Have setMainWindow check for Qt version and window modality and use XDG Dialog to make the parent-child relationship modal. M +3 -0 src/platforms/wayland/CMakeLists.txt M +15 -0 src/platforms/wayland/surfacehelper.h A +48 -0 src/platforms/wayland/waylandxdgdialogv1.cpp [License: LGPL(v2.0+)] A +36 -0 src/platforms/wayland/waylandxdgdialogv1_p.h [License: LGPL(v2.0+)] M +15 -0 src/platforms/wayland/windowsystem.cpp https://invent.kde.org/frameworks/kwindowsystem/-/commit/daa3cda4d4831b692f504f98aa6eeddabceb64a1 *** Bug 503064 has been marked as a duplicate of this bug. *** (In reply to Kai Uwe Broulik from comment #10) > Git commit daa3cda4d4831b692f504f98aa6eeddabceb64a1 by Kai Uwe Broulik. Kai, so if I understand you correctly, this should force back the modal dialog ("Save as" for example) into foreground in Chromium. I don't see any change. KDE Plasma Version: 6.3.80 (git-master from today) KDE Frameworks Version: 6.14.0 Qt Version: 6.9.0 I am using the steps as described here: https://bugs.kde.org/show_bug.cgi?id=502311 Is this the same issue or is this indeed a different issue? Works for me in Chrome. I right click → Save As and get a properly modal save dialog that remains ontop of the browser window. (In reply to Kai Uwe Broulik from comment #13) > Works for me in Chrome. I right click → Save As and get a properly modal > save dialog that remains ontop of the browser window. Thank you for the quick reply. This is probably what you mean, but just to clarify, it should come back into focus, if you open the modal, then focus on a different app entirely and then focus back on Chromium. Is this what you did? Ok, works for me now aswell. No idea why the change didn't show up first time I checked. Thanks. |
Created attachment 174075 [details] File picker is recognized (by not opening another one), but doesn't go back into focus. When you prompted to open the File Picker, but you had already opened it before, its window won't take focus. When the panel has auto-hide, the user could thing the file-picker is broken if they got sidetracked. PS: what happens when you summon the file picker from another site/app? A second file picker is summoned, or does it change where the file picker will send the files to?