micheleg
Slow start of flatpak application with Dash-to-dock enabled
When I run the Flatpak version of Chromium and Edge (which I use for work, sob), they take several minutes to start. With Dash to Dock disabled, I have no issues. The slow startup occurs only with Chromium and Edge; other apps start without delay. Additionally, if I start them with the commands gtk-launch org.chromium.Chromium or flatpak run org.chromium.Chromium, there is no delay
OS: Debian GNU/Linux trixie/sid x86_64 Kernel: 6.10.6-amd64 DE: GNOME 46.4 WM: Mutter Dash-to-dock: V95
The problem happens also when running the app from the overview or just from the dock?
The problem happens also when running the app from the overview or just from the dock?
both
I have the same iss, with dash-to-dock enabled in Fedora 41 with GNOME 47. After login, the starting of first application takes ~20+ seconds to appear its window. This includes both flatpak apps and non-flatpak apps. And when the first application started no further problem is present.
After checking the log, it seems that the issue is connected to the time comsumed to start xdg-desktop-portal-gnome.service and/or xdg-desktop-portal.service. (I don't know which one is the reason which is the consequence though) .
With dash to dock enabled, those 2 systemd user service would take ~20s to start compared ~1s in normal case. Hope this can help addressing the cause of the issue.
It could be related to https://gitlab.gnome.org/GNOME/xdg-desktop-portal-gnome/-/merge_requests/176 ?
@3v1n0 Yes it is, tried to update to 47.rc1 and application start now gets normal. Don't know why dash-to-dock has anything to do with triggering the bug here but is is solved with the update.
Well, the locations integration may play a role here, but I didn't go through all the details.
Closing then, thanks for testing!
The bug triggers by starting Nautilus. For 25 seconds after starting nautilus all GTK apps are delayed. Presumably dash-to-dock is starting nautilus (via dbus activation)
It could be related to https://gitlab.gnome.org/GNOME/xdg-desktop-portal-gnome/-/merge_requests/176 ?
That's not the case.
The problem is present only for Flatpak apps in particular for web browsers, in my case Chromoium and Edge. All other deb apps run with no delay even after the login.
https://github.com/user-attachments/assets/9b0d0948-318c-47ce-9863-3f3f6cb9bcb7
That's my situation:
With Dash to Dock disable all good, deb apps and flatpak apps run instantaneously even after the login, so no https://gitlab.gnome.org/GNOME/xdg-desktop-portal-gnome/-/merge_requests/176
With Dash to Dock enable deb apps run instantaneously, flatpak apps (web browser only) run after 2 or more minute delay, other flatpak apps run instantaneously (in the video Remmina but with other apps I have no issues)
@3v1n0 Yes it is, tried to update to 47.rc1 and application start now gets normal. Don't know why dash-to-dock has anything to do with triggering the bug here but is is solved with the update.
For me the problem is still there with gnome-shell 47.rc
When I run the Flatpak version of Chromium and Edge (which I use for work, sob), they take several minutes to start. With Dash to Dock disabled, I have no issues. The slow startup occurs only with Chromium and Edge; other apps start without delay. Additionally, if I start them with the commands
gtk-launch org.chromium.Chromiumorflatpak run org.chromium.Chromium, there is no delayOS: Debian GNU/Linux trixie/sid x86_64 Kernel: 6.10.6-amd64 DE: GNOME 46.4 WM: Mutter Dash-to-dock: V95
Forgot "gtk-launch org.chromium.Chromium" still true
Not much going on in this thread for a while, but I do have the same problem. Running VanillaOS Orchid (based on Debian Sid) and Gnome 46.
When DashToDock is enabled, launching Firefox from either the Dock or the Grid takes ages (minutes), launching it via flatpak run is near instant (I guess as instant as flatpaks get).
Disabling DashToDock resolves the issue.
Are there any updates to this bug?
Can you check if disabling the mounted locations support from settings improves the situation?
You may need to restart the shell
Hi @3v1n0, thanks for checking in. Sadly this does not solve the issue :/
Ok I'm quite happy it doesn't 😅, but I guess we've to go through trying disabling various elements to understand how to make things work properly...
Per se we don't touch the overview much... Another thing that could interact is the unity notifications support, try to toggle that instead
It's the Isolate Workspace and Isolate Monitors options. Just fiddled around with about each and every toggle in the "Launchers" section. Those seem to be the only ones effecting this issue. Is either of them on, Firefox takes ages to start. For reproduction: A shell restart is indeed necessary after each settings change.
It's the
Isolate WorkspaceandIsolate Monitorsoptions. Just fiddled around with about each and every toggle in the "Launchers" section. Those seem to be the only ones effecting this issue. Is either of them on, Firefox takes ages to start. For reproduction: A shell restart is indeed necessary after each settings change.
I can confirm. With Isolate Workspace and Isolate Monitors options disabled the app start instantaneously.
I have the same issue but I haven't found any fixes if anyone has one I would like to get it ! Thanks!
It's the
Isolate WorkspaceandIsolate Monitorsoptions. Just fiddled around with about each and every toggle in the "Launchers" section. Those seem to be the only ones effecting this issue. Is either of them on, Firefox takes ages to start. For reproduction: A shell restart is indeed necessary after each settings change.
When disabling those two functions application launch does speed up, but if the app is launched from an option in the right click menu, for example "new window", the problem persists and the app opens slowly.
This is most likely not a dash-to-dock related issue:
- https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/7958
- https://github.com/flatpak/flatpak/issues/6022
Please confirm either by installing flatpak 1.15.x pre-release or by enabling an apparmor profile.
This is most likely not a dash-to-dock related issue:
* https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/7958 * [[Bug]: 100% CPU when launching an app with a large RLIMIT_NOFILE soft limit flatpak/flatpak#6022](https://github.com/flatpak/flatpak/issues/6022)Please confirm either by installing flatpak 1.15.x pre-release or by enabling an apparmor profile.
Yes, I can confirm by enabling an apparmor profile.
But with some changes in the /etc/apparmor.d/flatpak file, because I have AppArmor 3.1.7
# This profile allows everything and only exists to give the
# application a name instead of having the label "unconfined"
abi <abi/3.0>,
include <tunables/global>
profile flatpak /usr/bin/flatpak flags=(attach_disconnected,mediate_deleted) {
# userns,
# Site-specific additions and overrides. See local/README for details.
include if exists <local/flatpak>
}
commend userns beacause generates a syntax error, unexpected TOK_END_OF_RULE, expecting TOK_MODE. But I don't know what I'm doing, I'm completely new to apparmor.
For memo Create an allow all profile and set a hard nofile limit in
/etc/apparmor.d/local/flatpakset rlimit nofile <= 1024, # Allow all capability, network, mount, remount, umount, ptrace, pivot_root, signal, dbus, file,
This is most likely not a dash-to-dock related issue:
* https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/7958 * [[Bug]: 100% CPU when launching an app with a large RLIMIT_NOFILE soft limit flatpak/flatpak#6022](https://github.com/flatpak/flatpak/issues/6022)Please confirm either by installing flatpak 1.15.x pre-release or by enabling an apparmor profile.
I can confirm by installing flatpak 1.15.x pre-release that this issue doesn't happen anymore.