Bug 458865 - After an update to qt5-base the dolphin file picker dialog used in GTK applications via GTK_USE_PORTAL=1 ignores theming
Summary: After an update to qt5-base the dolphin file picker dialog used in GTK applic...
Status: RESOLVED FIXED
Alias: None
Product: kde
Classification: I don't know
Component: general (show other bugs)
Version: unspecified
Platform: Arch Linux Linux
: VHI normal
Target Milestone: ---
Assignee: Unassigned bugs mailing-list
URL:
Keywords: regression
: 457668 458984 459540 459938 460099 460116 460174 460238 460364 460484 460639 460820 461220 461412 (view as bug list)
Depends on:
Blocks:
 
Reported: 2022-09-08 08:06 UTC by Moritz
Modified: 2023-06-02 06:30 UTC (History)
47 users (show)

See Also:
Latest Commit:
Version Fixed In: 5.26.2
Sentry Crash Report:


Attachments
coredumpctl gdb 912 (17.47 KB, text/plain)
2022-09-08 12:29 UTC, Moritz
Details
coredumpctl info 912 (80.84 KB, text/plain)
2022-09-08 12:29 UTC, Moritz
Details
backtrace coredumpctl gdb 912 full (18.66 KB, text/plain)
2022-09-08 12:33 UTC, Moritz
Details
journalctl --since 2022-09-01 -g 'org.freedesktop.impl' Output (113.70 KB, text/plain)
2022-09-09 21:44 UTC, Moritz
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Moritz 2022-09-08 08:06:57 UTC
SUMMARY
***
As per: https://wiki.archlinux.org/title/Uniform_look_for_Qt_and_GTK_applications#Consistent_file_dialog
I have set `GTK_USE_PORTAL=1` in `/etc/environment/`.
This make GTK applications use the Dolphin file picker dialog e.g. VSCode.

After updating qt5-base from version `5.15.5+kde+r182-1` to `5.15.5+kde+r184-1` the Dolphin file picker uses a light theme (instead of my system wide use of Breeze Dark and Icons are missing). This only applies to to GTK applications e.g. Kate still uses a dark themed Dolphin file picker dialog with correct icons.
***


STEPS TO REPRODUCE
1.  Set `GTK_USE_PORTAL=1` in `/etc/environment/`
2.  You should now have a Dophin file picker in e.g. VSCode which respects your KDE theme choice
3. Update your KDE arch system from `5.15.5+kde+r182-1` to `5.15.5+kde+r184-1`
4. Reboot
5. Now e.g. VSCode still uses the Dolphin file picker but ignores theming and icons are missing

See screenshots:

Before updating the system: https://imgur.com/a/JIRQ8ue
After update & reboot: https://imgur.com/a/mNEeNjg

OBSERVED RESULT
The Dolphin file picker dialog in GTK applications ignores theming and has missing icons.

EXPECTED RESULT
The Dolphin file picker dialog in GTK applications works as before the update: respecting my theme choice and with all the icons appearing. 

SOFTWARE/OS VERSIONS
Linux/KDE Plasma: 
(available in About System)
KDE Plasma Version:  5.25.5
KDE Frameworks Version: 5.97.0
Qt Version: 5.15.5

ADDITIONAL INFORMATION
Maybe this has something to do with: https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/4829 a
Comment 1 Moritz 2022-09-08 08:11:47 UTC
This bug also applies to the KDE Dolphin "File Upload / Save As - Portal" dialog in Firefox.
Before the qt5-base update the dialog in Firefox was dark themed and had all working icons.

https://imgur.com/5WzsMsN
Comment 2 Moritz 2022-09-08 10:56:29 UTC
I FIXED my issue by also adding `XDG_CURRENT_DESKTOP=KDE` to `/etc/environment/`.

Now the Dolphin File picker dialog respects my dark theme again and all the icons are there.

As to why it worked on an older KDE version without `/etc/environment/` - I don't know.
Comment 3 Nicolas Fella 2022-09-08 11:23:27 UTC
The file picker has nothing to do with Dolphin btw, it just happens to look similar.

I'm relatively sure this issues is caused by local circumstances in Arch, so there should be an update fixing it soon (if it hasn't happend already)
Comment 4 Antonio Rojas 2022-09-08 11:35:10 UTC
There have been reports of xdg-desktop-portal-kde crashing when updating qt5-base to the latest commit. I'm pretty sure this is what happened here, if you could dig in your coredumpctl and post a backtrace it would be quite useful.
Comment 5 Nicolas Fella 2022-09-08 11:37:21 UTC
My guess would be that it's related to the BIC change from https://invent.kde.org/qt/qt/qtbase/-/merge_requests/197#note_519320
Comment 6 Moritz 2022-09-08 12:24:42 UTC
(In reply to Antonio Rojas from comment #4)
> There have been reports of xdg-desktop-portal-kde crashing when updating
> qt5-base to the latest commit. I'm pretty sure this is what happened here,
> if you could dig in your coredumpctl and post a backtrace it would be quite
> useful.

Does this help? I have never done this. I followed: https://wiki.archlinux.org/title/Core_dump#Examining_a_core_dump

I used Timeshift to go back before the qt5-base update was installed, installed it, rebooted and opened Firefox and invoked a `Save As - Portal` dialog from Firefox (which was not dark themed & missing icons again).

I opened a terminal:

1) sudo coredumpctl list 
2) there was an entry: Thu 2022-09-08 14:02:53 CEST   912  970  970 SIGABRT present  /usr/lib/xdg-desktop-portal-kde
3) sudo coredumpctl gdb 912
4) (gdb) bt:

(gdb) bt
#0  0x00007fb890aa14dc in ?? () from /usr/lib/libc.so.6
#1  0x00007fb890a51998 in raise () from /usr/lib/libc.so.6
#2  0x00007fb890a3b53d in abort () from /usr/lib/libc.so.6
#3  0x00007fb89109fede in QMessageLogger::fatal(char const*, ...) const () from /usr/lib/libQt5Core.so.5
#4  0x00007fb891d3c9b5 in QGuiApplicationPrivate::createPlatformIntegration() () from /usr/lib/libQt5Gui.so.5
#5  0x00007fb891d3d019 in QGuiApplicationPrivate::createEventDispatcher() () from /usr/lib/libQt5Gui.so.5
#6  0x00007fb891292fab in QCoreApplicationPrivate::init() () from /usr/lib/libQt5Core.so.5
#7  0x00007fb891d3d0c9 in QGuiApplicationPrivate::init() () from /usr/lib/libQt5Gui.so.5
#8  0x00007fb892b75e2e in QApplicationPrivate::init() () from /usr/lib/libQt5Widgets.so.5
#9  0x00005637bcce60c6 in ?? ()
#10 0x00007fb890a3c2d0 in ?? () from /usr/lib/libc.so.6
#11 0x00007fb890a3c38a in __libc_start_main () from /usr/lib/libc.so.6
#12 0x00005637bcce7535 in ?? ()
(gdb) Quit

I add the full coredumpctl_gdb _912 command as attachment.
Comment 7 Moritz 2022-09-08 12:29:38 UTC
Created attachment 151922 [details]
coredumpctl gdb 912
Comment 8 Moritz 2022-09-08 12:29:49 UTC
Created attachment 151923 [details]
coredumpctl info 912
Comment 9 Moritz 2022-09-08 12:33:15 UTC
Created attachment 151924 [details]
backtrace coredumpctl gdb 912 full
Comment 11 Frederick Zhang 2022-09-09 16:53:53 UTC
@moritz1000 If you examine the output of `journalctl --since 2022-09-01 -g 'org.freedesktop.impl'`, do you also see that D-Bus started launching services for uid=996 (sddm) after the qt5 updates?

PS: Linking Arch tacker https://bugs.archlinux.org/task/75851
Comment 12 Antonio Rojas 2022-09-09 18:18:43 UTC
Can confirm that this is caused by https://invent.kde.org/qt/qt/qtbase/-/commit/2dc083df009a45c5dacfea27b0affeb85b01f847

It looks like the patch makes xdg-desktop-portal-kde launch "too soon", before even XDG_CURRENT_DESKTOP is set, so it doesn't pick up Plasma settings (confirmed by checking /proc/PID/environ). Restarting the service fixes the issue, since by then XDG_CURRENT_DESKTOP is already correctly set.
Comment 13 Moritz 2022-09-09 21:43:42 UTC
@Frederick Zhang Here are the logs for `journalctl --since 2022-09-01 -g 'org.freedesktop.impl'`, when I search for uid=996 in them I can't find anything BUT I have since then used Timeshift many times to jump back and forth between snapshots and again since I added `XDG_CURRENT_DESKTOP=KDE` as a workaround to `/etc/environment/` I don't have this issue anymore so I don't know how useful the logs will be!
Comment 14 Moritz 2022-09-09 21:44:52 UTC
Created attachment 151957 [details]
journalctl --since 2022-09-01 -g 'org.freedesktop.impl' Output
Comment 15 Koshika 2022-09-10 13:05:42 UTC
Desktop: KDE Plasma v: 5.25.5 tk: Qt v: 5.15.6 wm: kwin_x11 vt: 1 dm: SDDM 

I'm on X11

since this bug has been reported, QT 5.15.6 (qt5-base 5.15.6+kde+r165) has rolled out on Arch. that has in my setup fixed the coredump of service xdg-desktop-portal-kde. it starts with no failures. however file dialogs still default to gtk-file-dialog and not the kdialogs on google-chrome and on firefox as it used to be. restarting service xdg-desktop-portal-kde has no affect.
Comment 16 Demitrius Belai 2022-09-11 05:04:26 UTC
I have a issue with Firefox do not follow the dark theme before upgrade qt5-base (5.15.5+kde+r182-1 -> 5.15.5+kde+r184-1) on Arch Linux. I am pretty sure it is related.
I have tried `systemctl --user restart plasma-xdg-desktop-portal-kde.service` and it works.
Comment 17 Antonio Rojas 2022-09-11 06:48:01 UTC
*** Bug 458984 has been marked as a duplicate of this bug. ***
Comment 18 Matthias Mueller 2022-09-11 14:56:47 UTC
(In reply to Moritz from comment #13)
>  since I added `XDG_CURRENT_DESKTOP=KDE` as
> a workaround to `/etc/environment/` I don't have this issue anymore

Does this work for anyone else? I still have to restart plasma-xdg-desktop-portal-kde to get the dark theme applied.
Comment 19 Sandro 2022-09-11 18:24:43 UTC
(In reply to Matthias Mueller from comment #18)
> (In reply to Moritz from comment #13)
> >  since I added `XDG_CURRENT_DESKTOP=KDE` as
> > a workaround to `/etc/environment/` I don't have this issue anymore
> 
> Does this work for anyone else? I still have to restart
> plasma-xdg-desktop-portal-kde to get the dark theme applied.

Can confirm that this workaround works for me aswell.
Comment 20 Demitrius Belai 2022-09-11 19:25:28 UTC
(In reply to Matthias Mueller from comment #18)
> (In reply to Moritz from comment #13)
> >  since I added `XDG_CURRENT_DESKTOP=KDE` as
> > a workaround to `/etc/environment/` I don't have this issue anymore
> 
> Does this work for anyone else? I still have to restart
> plasma-xdg-desktop-portal-kde to get the dark theme applied.

Yes, it works. I just realize that I need a complete restart after that. A logout only does not work.
Comment 21 Frederick Zhang 2022-09-13 11:04:32 UTC
@Moritz Thank you. I guess uid=970 is sddm in your system? If so we have exactly the same issue then.

Setting XDG_CURRENT_DESKTOP=KDE in /etc/environment (or $HOME/.pam_environment if you use pam_env) did remediate this issue. And anyone who's using display scaling is probably gonna need those *_SCALE ones as well.
Comment 22 Bug Janitor Service 2022-09-13 11:55:46 UTC
A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/2109
Comment 23 Moritz 2022-09-13 20:57:37 UTC
(In reply to Frederick Zhang from comment #21)
> @Moritz Thank you. I guess uid=970 is sddm in your system?
According to my `coredumpctl info 912`  attachment I do think so.
Comment 24 Harald Sitter 2022-09-14 10:12:24 UTC
Git commit 9bf0e56da84de5e9bd2b3ff28bdb2cb1af6de91e by Harald Sitter.
Committed on 14/09/2022 at 10:05.
Pushed by sitter into branch 'master'.

delay ksplash until after env is set up

otherwise we can dbus invoke with the wrong environment. specifically
this happens with the latest qtbase changes that introduced color
picking support on wayland. when we start a qguiapplication with
incomplete environment that dbus invokes the xdg-portal system and that
in turn has an incomplete environment resulting in theming and the likes
not properly applying because the portal doesn't know that it runs
inside a plasma session.

https://invent.kde.org/qt/qt/qtbase/-/commit/2dc083df009a45c5dacfea27b0affeb85b01f847

M  +6    -4    startkde/startplasma-x11.cpp

https://invent.kde.org/plasma/plasma-workspace/commit/9bf0e56da84de5e9bd2b3ff28bdb2cb1af6de91e
Comment 25 Frederick Zhang 2022-09-14 11:47:01 UTC
@Harald Thanks for putting together the fix!

@Antonio backported the patch to Arch [1] and it's good to see the KDE file picker again.

However I noticed that the file picker doesn't respect my screen scaling. I have

    [KScreen]
    ScaleFactor=2
    ScreenScaleFactors=HDMI-0=2;DP-0=2;DP-1=2;DP-2=2;DP-3=2;DP-4=2;

...in ~/.config/kdeglobals, and xdg-desktop-portal-kde process does have the environment variables

    $ cat /proc/8318/environ | tr '\0' '\n' | rg SCALE
    GDK_DPI_SCALE=0.5
    GDK_SCALE=2
    QT_AUTO_SCREEN_SCALE_FACTOR=0
    QT_SCREEN_SCALE_FACTORS=HDMI-0=2;DP-0=2;DP-1=2;DP-2=2;DP-3=2;DP-4=2;

Restarting plasma-xdg-desktop-portal-kde.service fixes this issue. I'm not sure what I'm missing?

And by the way in journalctl it's still trying to start xdg-desktop-portal-kde for sddm user, which prints out a long crash backtrace.

[1] https://github.com/archlinux/svntogit-packages/commit/b0e1161ffcba6c19ab9c45afcc6e04343ed71348
Comment 26 Harald Sitter 2022-09-14 11:59:23 UTC
Git commit aa10c402f213269094532ee516b48951fe5b9066 by Harald Sitter.
Committed on 14/09/2022 at 11:59.
Pushed by sitter into branch 'Plasma/5.25'.

delay ksplash until after env is set up

otherwise we can dbus invoke with the wrong environment. specifically
this happens with the latest qtbase changes that introduced color
picking support on wayland. when we start a qguiapplication with
incomplete environment that dbus invokes the xdg-portal system and that
in turn has an incomplete environment resulting in theming and the likes
not properly applying because the portal doesn't know that it runs
inside a plasma session.

https://invent.kde.org/qt/qt/qtbase/-/commit/2dc083df009a45c5dacfea27b0affeb85b01f847
(cherry picked from commit 9bf0e56da84de5e9bd2b3ff28bdb2cb1af6de91e)

M  +5    -3    startkde/startplasma-x11.cpp

https://invent.kde.org/plasma/plasma-workspace/commit/aa10c402f213269094532ee516b48951fe5b9066
Comment 27 Harald Sitter 2022-09-14 11:59:53 UTC
Git commit 8817cce67ed039a538936d0041d33387a40dd1c6 by Harald Sitter.
Committed on 14/09/2022 at 11:59.
Pushed by sitter into branch 'Plasma/5.24'.

delay ksplash until after env is set up

otherwise we can dbus invoke with the wrong environment. specifically
this happens with the latest qtbase changes that introduced color
picking support on wayland. when we start a qguiapplication with
incomplete environment that dbus invokes the xdg-portal system and that
in turn has an incomplete environment resulting in theming and the likes
not properly applying because the portal doesn't know that it runs
inside a plasma session.

https://invent.kde.org/qt/qt/qtbase/-/commit/2dc083df009a45c5dacfea27b0affeb85b01f847
(cherry picked from commit 9bf0e56da84de5e9bd2b3ff28bdb2cb1af6de91e)
(cherry picked from commit aa10c402f213269094532ee516b48951fe5b9066)

M  +5    -3    startkde/startplasma-x11.cpp

https://invent.kde.org/plasma/plasma-workspace/commit/8817cce67ed039a538936d0041d33387a40dd1c6
Comment 28 Moritz 2022-09-14 16:23:08 UTC
@Harald, Thank you for the fix.

> delay ksplash until after env is set up

I removed my `XDG_CURRENT_DESKTOP=KDE` in `/etc/environment/` work-around, installed the newest Arch updates and rebooted my system: your fix works for me!

But I also still get the same `sudo coredumpctl list` entry as before / as @Frederick Zhang:
> Wed 2022-09-14 18:15:26 CEST   927  970  970 SIGABRT present  /usr/lib/xdg-desktop-portal-kde 

With this backtrace:
> sudo coredumpctl gdb 927
> (gdb) bt

#0  0x00007f289eca149c in ?? () from /usr/lib/libc.so.6
#1  0x00007f289ec51958 in raise () from /usr/lib/libc.so.6
#2  0x00007f289ec3b53d in abort () from /usr/lib/libc.so.6
#3  0x00007f289f29fede in QMessageLogger::fatal(char const*, ...) const () from /usr/lib/libQt5Core.so.5
#4  0x00007f289ff3caa5 in QGuiApplicationPrivate::createPlatformIntegration() () from /usr/lib/libQt5Gui.so.5
#5  0x00007f289ff3d109 in QGuiApplicationPrivate::createEventDispatcher() () from /usr/lib/libQt5Gui.so.5
#6  0x00007f289f49218b in QCoreApplicationPrivate::init() () from /usr/lib/libQt5Core.so.5
#7  0x00007f289ff3d1b9 in QGuiApplicationPrivate::init() () from /usr/lib/libQt5Gui.so.5
#8  0x00007f28a0d75e0e in QApplicationPrivate::init() () from /usr/lib/libQt5Widgets.so.5
#9  0x00005613c611f0c6 in ?? ()
#10 0x00007f289ec3c290 in ?? () from /usr/lib/libc.so.6
#11 0x00007f289ec3c34a in __libc_start_main () from /usr/lib/libc.so.6
#12 0x00005613c6120535 in ?? ()
Comment 29 Matthias Mueller 2022-09-15 06:22:02 UTC
Thanks for the Fix, Harald!
I can  confirm it works on my side too, despite the workaround not having an effect here.
Comment 30 tgnff242 2022-09-16 14:50:29 UTC
The patch has introduced a new bug in GTK software:

1. When using portal, the cursor, when hovering over the file picker, turns to Adwaita.
2. The cursor turns to Adwaita even when portal is not used, after invoking the context menu (eg. right-click somewhere in GIMP or Firefox).

If you change the cursor theme, it starts working properly until logging out.
Comment 31 Sandro 2022-09-17 00:24:39 UTC
I'm experiencing the same issue, was wondering if this is related to bug 448019
Comment 32 Antonio Rojas 2022-09-22 19:42:35 UTC
*** Bug 459540 has been marked as a duplicate of this bug. ***
Comment 33 Antonio Rojas 2022-10-01 09:07:39 UTC
Here is a diff of the xdg-desktop-portal-kde's environment right after login, and after manually restarting the service:
=============================
7c7
< SYSTEMD_EXEC_PID=2847
---
> SYSTEMD_EXEC_PID=4347
15a16
> GTK2_RC_FILES=/etc/gtk-2.0/gtkrc:/home/antonio/.gtkrc-2.0:/home/antonio/.config/gtkrc-2.0
16a18
> GTK_RC_FILES=/etc/gtk/gtkrc:/home/antonio/.gtkrc:/home/antonio/.config/gtkrc
27a30
> SESSION_MANAGER=local/arl:@/tmp/.ICE-unix/2869,unix/arl:/tmp/.ICE-unix/2869
30a34,35
> XCURSOR_SIZE=24
> XCURSOR_THEME=breeze_cursors
42,43c47,48
< INVOCATION_ID=490693277aac42f1951956c492e6e32a
< JOURNAL_STREAM=8:40285
---
> INVOCATION_ID=cfb4c3e28fd54b47b96895795b42a2a3
> JOURNAL_STREAM=8:45563
====================================================

So it looks like the service is still started before some env variables (related to kde-gtk-config) are properly set up.
Comment 34 Antonio Rojas 2022-10-01 10:22:57 UTC
According to the logs, xdg-desktop-portal is being activated by kapplymousetheme at

https://invent.kde.org/plasma/plasma-workspace/-/blob/v5.25.90/startkde/startplasma.cpp#L208

That's before the XCURSOR_* env variables are set.
Comment 35 Antonio Rojas 2022-10-03 13:10:04 UTC
*** Bug 459938 has been marked as a duplicate of this bug. ***
Comment 36 pixelplanetdev 2022-10-03 14:03:22 UTC
Got a similar issue on Fedora after the latest updates of plasma and qt.

GTK_USE_PORTAL=1 lost its effect and chrome and other applications would use xdg-desktop-portal-gtk instead.

After putting XDG_CURRENT_DESKTOP=KDE into /etc/environment it chooses the kde portal again.
However, it ignores scaling.

I'm on xorg,
qt5-qtbase.x86_64  5.15.6-1.fc36
xdg-desktop-portal-kde.x86_64  5.25.5-1.fc36
Comment 37 Antonio Rojas 2022-10-08 15:31:54 UTC
*** Bug 460116 has been marked as a duplicate of this bug. ***
Comment 38 Antonio Rojas 2022-10-08 15:35:08 UTC
*** Bug 460118 has been marked as a duplicate of this bug. ***
Comment 39 Nate Graham 2022-10-09 20:00:34 UTC
*** Bug 460099 has been marked as a duplicate of this bug. ***
Comment 40 Antonio Rojas 2022-10-09 20:01:47 UTC
*** Bug 460174 has been marked as a duplicate of this bug. ***
Comment 41 Nate Graham 2022-10-09 20:50:16 UTC
*** Bug 457668 has been marked as a duplicate of this bug. ***
Comment 42 Jinu 2022-10-10 00:05:25 UTC
(In reply to Harald Sitter from comment #24)
> Git commit 9bf0e56da84de5e9bd2b3ff28bdb2cb1af6de91e by Harald Sitter.
> Committed on 14/09/2022 at 10:05.
> Pushed by sitter into branch 'master'.
> 
> delay ksplash until after env is set up
> 
> otherwise we can dbus invoke with the wrong environment. specifically
> this happens with the latest qtbase changes that introduced color
> picking support on wayland. when we start a qguiapplication with
> incomplete environment that dbus invokes the xdg-portal system and that
> in turn has an incomplete environment resulting in theming and the likes
> not properly applying because the portal doesn't know that it runs
> inside a plasma session.
> 
> https://invent.kde.org/qt/qt/qtbase/-/commit/
> 2dc083df009a45c5dacfea27b0affeb85b01f847
> 
> M  +6    -4    startkde/startplasma-x11.cpp
> 
> https://invent.kde.org/plasma/plasma-workspace/commit/
> 9bf0e56da84de5e9bd2b3ff28bdb2cb1af6de91e

Can someone please tell me how to apply Harald Sitter's solution step by step?
Comment 43 medin 2022-10-10 11:26:07 UTC
On Manjaro, it seems the cursor problem inside portal open/save dialogs comes from the file "/usr/share/icons/default/index.theme"
it contains:
[icon theme]
Inherits=xcursor-breeze

after changing it to:
[icon theme]
Inherits=breeze_cursors

After rebooting, it seems the problem is gone.
Comment 44 Antonio Rojas 2022-10-11 12:28:38 UTC
*** Bug 460238 has been marked as a duplicate of this bug. ***
Comment 45 Adam Williamson 2022-10-12 09:28:49 UTC
So we have folks running into this on Fedora: https://bugzilla.redhat.com/show_bug.cgi?id=2133795

It looks like we don't have the change from this bug report yet. However, Fedora users will generally be on Wayland, and the change from this bug report is only to startplasma-x11.cpp. I notice that in startplasma-wayland.cpp , `setupCursor` still happens very early - in fact it's nearly the *first* thing that happens. Does it need to be delayed on Wayland too?

I'll poke around at this a bit myself if I have time.
Comment 46 Antonio Rojas 2022-10-12 10:01:17 UTC
(In reply to Adam Williamson from comment #45)
> So we have folks running into this on Fedora:
> https://bugzilla.redhat.com/show_bug.cgi?id=2133795
> 
> It looks like we don't have the change from this bug report yet. However,
> Fedora users will generally be on Wayland, and the change from this bug
> report is only to startplasma-x11.cpp. I notice that in
> startplasma-wayland.cpp , `setupCursor` still happens very early - in fact
> it's nearly the *first* thing that happens. Does it need to be delayed on
> Wayland too?

For the Wayland session, when setupCursor is called is irrelevant for this issue, because on Wayland setupCursor does not launch kapplymousetheme (or any other QApplication) [1], so it doesn't activate xdg-desktop-portal

[1] https://invent.kde.org/plasma/plasma-workspace/-/blob/v5.26.0/startkde/startplasma.cpp#L208  

Is anybody actually reporting wrong cursors on Wayland on Fedora? AFAICS the downstream bug report is about xdg-desktop-portal-kde crashes for the sddm user, which is also caused by the Qt change, but is unrelated to the wrong cursors issue.
Comment 47 Adam Williamson 2022-10-12 10:29:57 UTC
(In reply to Antonio Rojas from comment #46)
> (In reply to Adam Williamson from comment #45)
> > So we have folks running into this on Fedora:
> > https://bugzilla.redhat.com/show_bug.cgi?id=2133795
> > 
> > It looks like we don't have the change from this bug report yet. However,
> > Fedora users will generally be on Wayland, and the change from this bug
> > report is only to startplasma-x11.cpp. I notice that in
> > startplasma-wayland.cpp , `setupCursor` still happens very early - in fact
> > it's nearly the *first* thing that happens. Does it need to be delayed on
> > Wayland too?
> 
> For the Wayland session, when setupCursor is called is irrelevant for this
> issue, because on Wayland setupCursor does not launch kapplymousetheme (or
> any other QApplication) [1], so it doesn't activate xdg-desktop-portal
> 
> [1]
> https://invent.kde.org/plasma/plasma-workspace/-/blob/v5.26.0/startkde/
> startplasma.cpp#L208  
> 
> Is anybody actually reporting wrong cursors on Wayland on Fedora? AFAICS the
> downstream bug report is about xdg-desktop-portal-kde crashes for the sddm
> user, which is also caused by the Qt change, but is unrelated to the wrong
> cursors issue.

Well, I was following on from your comment 34, but now I see that yeah, it doesn't run `kapplymousetheme` on Wayland.

Yes, the downstream report is just about the crash under SDDM. I got here via the Arch report, and both do seem to discuss that crash. Is there a different bug report for that? Do we know what's causing it / have a fix?

I don't think we know yet if there are any practical consequences of it, it's more just that people are noticing the crash report.

Thanks!
Comment 48 Antonio Rojas 2022-10-12 11:47:27 UTC
(In reply to Adam Williamson from comment #47)
> Yes, the downstream report is just about the crash under SDDM. I got here
> via the Arch report, and both do seem to discuss that crash. Is there a
> different bug report for that? Do we know what's causing it / have a fix?
> 
> I don't think we know yet if there are any practical consequences of it,
> it's more just that people are noticing the crash report.

After the Qt change, sddm-greeter dbus-activates xdg-desktop-portal on startup. xdg-desktop-portal-kde then tries to connect to sddm's X server, it is blocked (by xauth I guess), so it crashes. So far it has been tracked here (together with all other regressions from the Qt patch), not sure if it makes sense to open a different report for it since it's not a KDE issue, strictly speaking.
Comment 49 Adam Williamson 2022-10-12 11:48:44 UTC
oof, and I just realized...we do actually run SDDM on X on Fedora (because it has bugs running on Wayland). So the patch from this issue is probably relevant to that case after all...
Comment 50 Antonio Rojas 2022-10-13 16:24:50 UTC
*** Bug 460364 has been marked as a duplicate of this bug. ***
Comment 51 Nate Graham 2022-10-15 14:24:44 UTC
*** Bug 460484 has been marked as a duplicate of this bug. ***
Comment 52 Antonio Rojas 2022-10-18 08:11:15 UTC
*** Bug 460639 has been marked as a duplicate of this bug. ***
Comment 53 Bug Janitor Service 2022-10-24 11:19:25 UTC
A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/2257
Comment 54 Harald Sitter 2022-10-24 13:09:40 UTC
Git commit 670cf731a75037c646864ed0bd03a35a35130c5e by Harald Sitter.
Committed on 24/10/2022 at 13:09.
Pushed by sitter into branch 'master'.

disable automatic portal launching early on

this opts out of color picking support early on in the login process
when our environment is still incomplete. not doing this would cause the
portal system to launch "too early" and have an incomplete environment
set. instead disable the portal support early on and only enable it once
we have a working environment constructed.

also move cursor setup and ksplash into this newly available "critical
section". now that we have an opt out we can run them as early as
necessary without risking them starting the portal infrastructure.

M  +7    -6    startkde/startplasma-x11.cpp

https://invent.kde.org/plasma/plasma-workspace/commit/670cf731a75037c646864ed0bd03a35a35130c5e
Comment 55 Harald Sitter 2022-10-24 13:10:11 UTC
Git commit 8c8c110a934a9abd7e69762f89f4029bea7f9c4a by Harald Sitter.
Committed on 24/10/2022 at 13:10.
Pushed by sitter into branch 'Plasma/5.26'.

disable automatic portal launching early on

this opts out of color picking support early on in the login process
when our environment is still incomplete. not doing this would cause the
portal system to launch "too early" and have an incomplete environment
set. instead disable the portal support early on and only enable it once
we have a working environment constructed.

also move cursor setup and ksplash into this newly available "critical
section". now that we have an opt out we can run them as early as
necessary without risking them starting the portal infrastructure.


(cherry picked from commit 670cf731a75037c646864ed0bd03a35a35130c5e)

M  +7    -6    startkde/startplasma-x11.cpp

https://invent.kde.org/plasma/plasma-workspace/commit/8c8c110a934a9abd7e69762f89f4029bea7f9c4a
Comment 56 Nate Graham 2022-10-24 20:31:30 UTC
*** Bug 460820 has been marked as a duplicate of this bug. ***
Comment 57 Harald Sitter 2022-11-02 00:50:49 UTC
*** Bug 461220 has been marked as a duplicate of this bug. ***
Comment 58 Antonio Rojas 2022-11-04 11:42:29 UTC
*** Bug 461412 has been marked as a duplicate of this bug. ***
Comment 59 Patrick Silva 2022-11-04 11:47:48 UTC
(In reply to Antonio Rojas from comment #58)
> *** Bug 461412 has been marked as a duplicate of this bug. ***

This duplicate was reported against the supposedly fixed Plasma 5.26.2. I can confirm that the crash persists on Plasma 5.26.2.
Comment 60 Nicolas Fella 2022-11-04 11:49:57 UTC
https://invent.kde.org/qt/qt/qtbase/-/commit/725ab072130ca3ce4104f4351e48fe50f57ae330 is needed for the fix to be effective
Comment 61 Antonio Rojas 2022-11-04 11:51:45 UTC
(In reply to Nicolas Fella from comment #60)
> https://invent.kde.org/qt/qt/qtbase/-/commit/
> 725ab072130ca3ce4104f4351e48fe50f57ae330 is needed for the fix to be
> effective

And https://github.com/sddm/sddm/commit/fc24321541f6f65b7d1aac89cd82336ffd53e1a0 (for the xdg-desktop-portal-kde crash)
Comment 62 Charles Dennett 2022-11-30 15:45:24 UTC
Looks like the problem still exists in Plasma 5.26.3.  I'm running that on Fedora 37.
Comment 63 silocoder 2023-03-02 00:45:24 UTC
(In reply to Demitrius Belai from comment #16)
> I have a issue with Firefox do not follow the dark theme before upgrade
> qt5-base (5.15.5+kde+r182-1 -> 5.15.5+kde+r184-1) on Arch Linux. I am pretty
> sure it is related.
> I have tried `systemctl --user restart
> plasma-xdg-desktop-portal-kde.service` and it works.

Works for me too.