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
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
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.
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)
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.
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
(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.
Created attachment 151922 [details] coredumpctl gdb 912
Created attachment 151923 [details] coredumpctl info 912
Created attachment 151924 [details] backtrace coredumpctl gdb 912 full
Looks like I am not the only person with this isse: 1) https://old.reddit.com/r/kde/comments/x8we1a/problems_to_gtk_themes_after_arch_update/ 2) https://bbs.archlinux.org/viewtopic.php?id=279527
@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
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.
@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!
Created attachment 151957 [details] journalctl --since 2022-09-01 -g 'org.freedesktop.impl' Output
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.
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.
*** Bug 458984 has been marked as a duplicate of this bug. ***
(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.
(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.
(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.
@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.
A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/2109
(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.
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
@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
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
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
@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 ?? ()
Thanks for the Fix, Harald! I can confirm it works on my side too, despite the workaround not having an effect here.
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.
I'm experiencing the same issue, was wondering if this is related to bug 448019
*** Bug 459540 has been marked as a duplicate of this bug. ***
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.
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.
*** Bug 459938 has been marked as a duplicate of this bug. ***
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
*** Bug 460116 has been marked as a duplicate of this bug. ***
*** Bug 460118 has been marked as a duplicate of this bug. ***
*** Bug 460099 has been marked as a duplicate of this bug. ***
*** Bug 460174 has been marked as a duplicate of this bug. ***
*** Bug 457668 has been marked as a duplicate of this bug. ***
(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?
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.
*** Bug 460238 has been marked as a duplicate of this bug. ***
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.
(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.
(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!
(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.
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...
*** Bug 460364 has been marked as a duplicate of this bug. ***
*** Bug 460484 has been marked as a duplicate of this bug. ***
*** Bug 460639 has been marked as a duplicate of this bug. ***
A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/2257
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
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
*** Bug 460820 has been marked as a duplicate of this bug. ***
*** Bug 461220 has been marked as a duplicate of this bug. ***
*** Bug 461412 has been marked as a duplicate of this bug. ***
(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.
https://invent.kde.org/qt/qt/qtbase/-/commit/725ab072130ca3ce4104f4351e48fe50f57ae330 is needed for the fix to be effective
(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)
Looks like the problem still exists in Plasma 5.26.3. I'm running that on Fedora 37.
(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.