Busy cursor persists ~30s after launch on GNOME/Wayland: activation token reaches Chrome but the startup sequence is never completed

[gianmarco-cangemi]

Summary

When Chrome is launched from a graphical launcher on GNOME/Wayland, the "busy"
(spinner) cursor keeps running for about 30 seconds. Chrome itself is up and fully
usable within a second — the window is mapped, responsive and correctly matched to
its app icon. Only the launch feedback is stuck, until it eventually times out.

Launching with flatpak run com.google.Chrome from a terminal never shows the
problem, because that path never opens a startup sequence in the first place.

This looks like the same symptom as #308 (closed, June 2024), which is still
reproducible almost two years later on a current GNOME.

Environment

• Fedora 44, GNOME Shell 50.3, Wayland
• mutter 50.3, gnome-shell 50.3
• xdg-desktop-portal 1.22.1, xdg-desktop-portal-gnome 50.0
• Flatpak 1.18.0
• com.google.Chrome 150.0.7871.186-1, branch stable
• Runtime org.freedesktop.Platform/x86_64/25.08

Steps to reproduce

1. Make sure Chrome is not running.
2. Launch it from the GNOME Activities overview or from a dock.
3. The window appears almost immediately and is usable.
4. The busy cursor keeps spinning for ~30 seconds regardless.

Expected vs actual

Expected: launch feedback stops as soon as the window is up.
Actual: it stops only when the startup sequence times out. The duration is
always the same, independent of machine load or of how long Chrome actually takes —
which is what identifies it as a timeout rather than real work.

What I verified

I traced the activation token through every hop:

1. GNOME issues a token. The problem only occurs on launch paths that create a
   startup sequence. Launching from a terminal, which does not, never reproduces it.
2. Flatpak forwards it into the sandbox.
   XDG_ACTIVATION_TOKEN=test flatpak run --command=sh com.google.Chrome -c 'echo $XDG_ACTIVATION_TOKEN'
   prints the token. DESKTOP_STARTUP_ID is forwarded too.
3. The token reaches the real Chrome process. Launching with
   XDG_ACTIVATION_TOKEN=TEST-98765 flatpak run com.google.Chrome and then reading
   /proc/<chrome-pid>/environ shows XDG_ACTIVATION_TOKEN=TEST-98765 in the
   environment of the browser process itself, not just of the sandbox shell.

So the token is delivered end to end, and is simply never used to complete the
startup sequence.

Ruled out

• Not com.google.Chrome.desktop - StartupWMClass #83 / [Bug]: Missing StartupWMClass in main [Desktop Entry] causes double icons on KDE Plasma (Wayland) #465 (misplaced StartupWMClass). In the currently shipped
  .desktop file, StartupWMClass=google-chrome is correctly inside
  [Desktop Entry] (line 106, before the [Desktop Action] groups). The window is
  matched to the app: a single dock icon, no ghost entry.
• Not slow startup. Chrome reaches a responsive window in ~0.2 s, whether
  launched from the terminal or through its .desktop file with gio launch.
• Not the user profile. Same behaviour with a clean --user-data-dir.
• Not the sandbox or the portals. Both the app and the portals start normally,
  and nothing is logged by gnome-shell during the stuck period.

Workaround

Overriding the desktop entry with StartupNotify=false removes the stuck cursor
completely:

cp /var/lib/flatpak/exports/share/applications/com.google.Chrome.desktop \
   ~/.local/share/applications/
sed -i 's/^StartupNotify=true$/StartupNotify=false/' \
   ~/.local/share/applications/com.google.Chrome.desktop
update-desktop-database ~/.local/share/applications

The cost is losing launch feedback for Chrome — acceptable here only because that
feedback was already meaningless, staying on for half a minute after the app was
ready.

Note on where this belongs

Since the token is delivered correctly all the way to the browser process, this may
well be an upstream Chromium issue in the ozone/Wayland startup-notification
handling rather than a packaging one, and I understand if it needs to be redirected
there. I am reporting it here because this is where users of the Flatpak will look,
because #308 was closed without a recorded cause, and because shipping
StartupNotify=false in the manifest is a mitigation available at packaging level
while upstream is sorted out.

I am happy to run further tests on this machine if that helps.