Slow start of flatpak application with Dash-to-dock enabled

[emagra]

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

[3v1n0]

The problem happens also when running the app from the overview or just from the dock?

[vanvugt]

See also #2266

[emagra]

The problem happens also when running the app from the overview or just from the dock?

both

[karuboniru]

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.

[3v1n0]

It could be related to https://gitlab.gnome.org/GNOME/xdg-desktop-portal-gnome/-/merge_requests/176 ?

[karuboniru]

@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.

[3v1n0]

Well, the locations integration may play a role here, but I didn't go through all the details.

Closing then, thanks for testing!

[aleasto]

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)

[emagra]

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.

[emagra]

Screencast.From.2024-09-10.17-45-24.mp4

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.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

Forgot "gtk-launch org.chromium.Chromium" still true

[marvin-te]

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?

[3v1n0]

Can you check if disabling the mounted locations support from settings improves the situation?

You may need to restart the shell

[marvin-te]

Hi @3v1n0, thanks for checking in. Sadly this does not solve the issue :/

[3v1n0]

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

[marvin-te]

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.

[emagra]

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.

I can confirm. With Isolate Workspace and Isolate Monitors options disabled the app start instantaneously.