flathub / flathub/com.google.Chrome

🐞 Bug Report: Chrome Flatpak becomes unclickable after workspace switch on GNOME Shell

Open
#399 0 comments 0 reactions 0 assignees View on GitHub
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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.