Firefox + KDE causes system unable to auto sleep

Help
, ,
1

I found a bug that could be KDE’s or Firefox’s.

A little background: I tell GTK apps to use Qt file picker (set KDE portal as default)

Steps to reproduce bug:

  1. Use latest Firefox (153-156) to open a picture URL (eg https://www.w3schools.com/html/workplace.jpg )
  2. Use context menu “Save Image As”
  3. In the Qt file picker, select a path and click Save

Then, system starts to be unable to auto sleep. (30 mins idle to sleep, set in KDE systemsettings, which is PowerDevil’s job)

Watch PowerDevil status:

watch qdbus6 --literal \
  org.kde.Solid.PowerManagement \
  /org/kde/Solid/PowerManagement/PolicyAgent \
  org.kde.Solid.PowerManagement.PolicyAgent.ListInhibitions

“Save Image As” will register this “Download in progress” status, and never cancle it, even after image finished saving:

[Argument: a(ss) {[Argument: (ss) "org.kde.konsole", "Download in progress"]}]

I manually restarted PowerDevil to get its debug log:

export QT_LOGGING_RULES="org.kde.powerdevil.debug=true"
/usr/lib/x86_64-linux-gnu/libexec/org_kde_powerdevil --replace

PowerDevil log:

org.kde.powerdevil: Scheduling inhibition from ":1.65" "org.kde.konsole" with cookie 15 and reason "Download in progress"
org.kde.powerdevil: Enforcing inhibition from ":1.65" "org.kde.konsole" with cookie 15 and reason "Download in progress"
org.kde.powerdevil: Added interrupt session
org.kde.powerdevil: Refreshing timers for actions on inhibitionsChanged

Notice that :1.65 was used by process xdg-desktop-portal-kde.
Firefox does not directly register “Downloading” status, but via KDE portal.

This is how I set KDE portal as default:

export GTK_USE_PORTAL=1

~/.config/xdg-desktop-portal/portals.conf:

[preferred]
default=kde
org.freedesktop.impl.portal.FileChooser=kde

I want to report bug to developer. Yet I’m not sure it is KDE portal’s or Firefox’s bug. Could you guys check if you can reproduce?

My OS info:

Operating System: Debian GNU/Linux 13
KDE Plasma Version: 6.3.6
KDE Frameworks Version: 6.13.0
Qt Version: 6.8.2
Graphics Platform: X11
Firefox: 156 or 153
2

yeah that stuck “Download in progress” inhibition is almost certainly xdg-desktop-portal-kde never clearing the request after the save finishes. firefox asked the portal, the portal told powerdevil to block sleep, then nobody released the cookie.

quick unblock when it happens:

qdbus6 org.kde.Solid.PowerManagement /org/kde/Solid/PowerManagement/PolicyAgent org.kde.Solid.PowerManagement.PolicyAgent.ListInhibitions

systemctl --user restart plasma-xdg-desktop-portal-kde.service

or restart PowerDevil like you already did.

id file it against xdg-desktop-portal-kde first (inhibition reason owned by the portal, shows up as konsole/portal in the list). mention GTK_USE_PORTAL=1 + Save Image As. firefox side is worth a cc if they leave the portal request hanging.

until it gets fixed, just avoid the kde filechooser for that one action, or clear the inhibition after saves.

3

Also interesting that it would show Konsole as the one requesting the inhibition.

4

I started Firefox from Konsole. If I start Firefox by a bash script, the script name will be used.

A simplified dbus log:

0.741288
Firefox  -> xdg-desktop-portal
org.freedesktop.portal.Inhibit.Inhibit(
    app_id = "firefox",
    flags = 4,
    reason = "Download in progress"
)

0.744271
xdg-desktop-portal returned request path to Firefox:
/org/freedesktop/portal/desktop/request/1_6531/t/4082638740

0.745949
xdg-desktop-portal  -> xdg-desktop-portal-kde
org.freedesktop.impl.portal.Inhibit.Inhibit(
    request = "/org/freedesktop/portal/desktop/request/1_6531/t/4082638740",
    app = "start_firefox.sh",
    app_id = "firefox",
    flags = 4,
    reason = "Download in progress"
)

............
5

I’ve reported: https://bugs.kde.org/show_bug.cgi?id=525467

Because it involves four softwares:

  • Firefox
  • xdg-desktop-portal
  • xdg-desktop-portal-kde
  • PowerDevil

Currently, PowerDevil seems innocent. I’ve reported to KDE portal. I’m considering if we should report to Mozilla/Flatpak/Freedesktop too?

6

Ah, that looks as if it is not related to the file picker but Firefox requesting inhibition itself.

I wonder if Firefox is not closing the request after it is done downloading.

7

The full log (in the ticket attachment) shows Firefox does close.
Because the download file is small, close request is so fast that portal fails to handle