https://bugs.kde.org/show_bug.cgi?id=522394

            Bug ID: 522394
           Summary: xdg-desktop-portal-kde spinlocks when selecting "Open
                    Folder" with no choices field on Niri
    Classification: Plasma
           Product: xdg-desktop-portal-kde
      Version First 6.7.1
       Reported In:
          Platform: CachyOS
                OS: Linux
            Status: REPORTED
          Severity: major
          Priority: NOR
         Component: general
          Assignee: [email protected]
          Reporter: [email protected]
                CC: [email protected]
  Target Milestone: ---

DESCRIPTION
Using an electron application that calls out to the FileChooser portal (in my
case, VSCodium) using the OpenFile + directory=true and no choices field, the
KDE portal will never open the file picker (original application just freezes)
and CPU usage will be driven up to max. killing xdg-desktop-portal-kde
unfreezes the original application. This behavior has been happening since I
updated my system on June 28th, so I cannot be sure of when exactly this issue
started happening (as I also tweaked some qt6ct settings on the same day to
make sure the filechooser is the portal one rather than the default qt one).

STEPS TO REPRODUCE
Using niri (or another non-KDE wayland WM, I suppose), with FileChooser=kde in
portal settings and qt6ct Standard Dialogs set to XDG Desktop Portal, try the
following commands:
```
# kill existing portal instance before every rerun
pkill -f xdg-desktop-portal-kde

##### Using qt6ct platformtheme (runs through plasma-integration) #####
# directory without choices -- this freezes
QT_QPA_PLATFORMTHEME=qt6ct /usr/lib/xdg-desktop-portal-kde &
sleep 2 && gdbus call --session --dest org.freedesktop.portal.Desktop \
  --object-path /org/freedesktop/portal/desktop \
  --method org.freedesktop.portal.FileChooser.OpenFile \
  '' 'Pick a folder' '{"directory": <true>}'

pkill -f xdg-desktop-portal-kde
# directory with choices -- this works
QT_QPA_PLATFORMTHEME=qt6ct /usr/lib/xdg-desktop-portal-kde &
sleep 2 && gdbus call --session --dest org.freedesktop.portal.Desktop \
  --object-path /org/freedesktop/portal/desktop \
  --method org.freedesktop.portal.FileChooser.OpenFile \
  '' 'Pick a folder' '{"directory": <true>, "choices": <[("encoding",
"Encoding", [("utf8", "UTF-8"), ("ascii", "ASCII")], "utf8")]>}'

pkill -f xdg-desktop-portal-kde
##### Using null platformtheme (Qt defaults, I imagine?) #####
# directory without choices -- this works: shows Qt built-in dialog rather than
the nice filechooser that looks like dolphin
QT_QPA_PLATFORMTHEME= /usr/lib/xdg-desktop-portal-kde &
sleep 2 && gdbus call --session --dest org.freedesktop.portal.Desktop \
  --object-path /org/freedesktop/portal/desktop \
  --method org.freedesktop.portal.FileChooser.OpenFile \
  '' 'Pick a folder' '{"directory": <true>}'

OBSERVED RESULT
See above.

EXPECTED RESULT
Both methods of calling the FileChooser shouldn't spinlock :-)

SOFTWARE/OS VERSIONS
CachyOS Linux, kernel 6.18.36-1-cachyos-lts
niri v26.04-36-g49fc6117 (Wayland)
xdg-desktop-portal-kde 6.7.1-1.1 (stock)
xdg-desktop-portal 1.22.1-2.1
plasma-integration 6.7.1-1.1
qt6-base 6.11.1-1.1
kio 6.27.0-1.1
XDG_CURRENT_DESKTOP=niri


ADDITIONAL INFORMATION

This one-line patch seems to fix the issue for me by bypassing the QFileDialog
path (which goes through `plasma-integration` => KDirSelectDialog), and always
using KFileWidget instead, same as when the `choices` value is filled in:

```
--- a/src/filechooser.cpp
+++ b/src/filechooser.cpp
@@ -417,7 +417,7 @@

     // Use QFileDialog for most directory requests to utilize
     // plasma-integration's KDirSelectDialog
-    if (directory && !options.contains(QStringLiteral("choices"))) {
+    if (false && directory && !options.contains(QStringLiteral("choices"))) {
         auto dirDialog = new QFileDialog;
         dirDialog->setWindowTitle(title);
         dirDialog->setFileMode(QFileDialog::Directory);
```

Of course, just skipping the whole thing probably isn't an ideal patch.
Asking a clanker for analysis tells me something about how
`QGuiApplicationPrivate::isWindowBlocked() enters an infinite loop because
there's no transient parent window on niri`, but I frankly have no way of
confirming whether that's a red herring or not. Still, I figured I'd include
that in anyway...

-- 
You are receiving this mail because:
You are watching all bug changes.

Reply via email to