flathub / flathub/com.google.Chrome
🐞 Bug Report: Chrome Flatpak becomes unclickable after workspace switch on GNOME Shell
- Dominant language
- Shell
- Stars
- 67
- Forks
- 39
- Avg merge
- 6h 48m
- Merged PRs (30d)
- 7
Description
Environment:
OS: Fedora Silverblue 40 (immutable)
Desktop: GNOME Shell 46 (Wayland session)
Chrome version: Latest Flatpak version (from Flathub)
Flatpak version: up-to-date (default from Fedora 40)
GPU: Intel integrated (Mesa drivers)
Problem started: after last Flatpak update for Chrome
Problem description:
After switching to another workspace and returning, the Chrome window becomes unclickable. The mouse cursor is visible and moves, but no interaction (clicks, tabs, scrolling) is possible inside the Chrome window.
This only happens with Chrome installed via Flatpak. Other Flatpak apps (like Firefox) are unaffected. The issue does not occur with Chrome installed via RPM inside a Toolbox or Distrobox.
Tested workarounds (none solved the issue):
Running with --ozone-platform=x11
Running with --disable-gpu
Running with --enable-features=UseOzonePlatform
Using different Chrome profiles
Using different Chrome channels (stable/beta)
Relevant logs:
bash
Copiar
Editar
Gtk-Message: Failed to load module "canberra-gtk-module"
ERROR: GetVSyncParametersIfAvailable() failed
ERROR: Registration response error message: DEPRECATED_ENDPOINT
Temporary workaround:
Switching to "GNOME on Xorg" avoids the problem, but Wayland is the default on Fedora and should be supported.
Steps to reproduce:
Open Chrome (Flatpak) on Wayland
Move to a different GNOME workspace
Come back to the original workspace
Chrome becomes unclickable (mouse input doesn't register)
Expected behavior:
Chrome remains responsive after workspace changes.
Contributor guide
No contributing guide indexed for this repository
Research direction
Start by reproducing the issue on Fedora Silverblue 40 with GNOME Shell 46, a Wayland session, and Chrome from Flathub, following the listed workspace-switch steps. Compare the listed logs and workarounds with the RPM-in-Toolbox or Distrobox behavior; done means Chrome remains clickable and responsive after returning to its workspace without requiring GNOME on Xorg.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- linux
- Domain
- desktop, operating-systems
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100