GNOME Bugzilla – Bug 789691
No mouse event sent to application
Last modified: 2021-07-05 14:12:57 UTC
gnome-shell just has been in a state where the mouse worked fine on the panel and in window decorations, but clicking anything inside any application had no effect whatsoever. Somehow, no mouse events were forwarded to applications. This affected all applications. Restarting the shell fixed the issue. I have not been able to reproduce this yet, and only observed it once. The journal for the relevant timeframe looks as follows: Okt 31 10:32:02 r-thinktop gnome-shell[7044]: g_signal_handler_disconnect: assertion 'handler_id > 0' failed Okt 31 10:32:02 r-thinktop gnome-shell[7044]: g_signal_handler_disconnect: assertion 'handler_id > 0' failed Okt 31 10:32:06 r-thinktop gnome-terminal-[1459]: Allocating size to GtkScrollbar 0x555ada0ce3f0 without calling gtk_widget_get_preferred_width/height(). How does the code know the size to allocate? Okt 31 10:32:07 r-thinktop gnome-shell[7044]: st_widget_get_theme_node called on the widget [0x564835196c90 StIcon:last-child first-child] which is not in the stage. Okt 31 10:32:07 r-thinktop gnome-shell[7044]: st_widget_get_theme_node called on the widget [0x564837339890 StIcon:last-child first-child] which is not in the stage. Okt 31 10:32:07 r-thinktop gnome-shell[7044]: st_widget_get_theme_node called on the widget [0x5648387abeb0 StIcon:last-child first-child] which is not in the stage. Okt 31 10:32:07 r-thinktop gnome-shell[7044]: st_widget_get_theme_node called on the widget [0x5648361bf090 StIcon:last-child first-child] which is not in the stage. Okt 31 10:32:07 r-thinktop gnome-shell[7044]: st_widget_get_theme_node called on the widget [0x564831f22c90 StIcon:last-child first-child] which is not in the stage. Okt 31 10:32:07 r-thinktop gnome-shell[7044]: st_widget_get_theme_node called on the widget [0x564837880490 StIcon:last-child first-child] which is not in the stage. Okt 31 10:32:07 r-thinktop gnome-shell[7044]: st_widget_get_theme_node called on the widget [0x564836e4a730 StIcon:last-child first-child] which is not in the stage. Okt 31 10:32:07 r-thinktop gnome-shell[7044]: st_widget_get_theme_node called on the widget [0x564836154fa0 StIcon:last-child first-child] which is not in the stage. Okt 31 10:32:07 r-thinktop gnome-shell[7044]: st_widget_get_theme_node called on the widget [0x564836eeefd0 StIcon:last-child first-child] which is not in the stage. Okt 31 10:32:07 r-thinktop gnome-shell[7044]: st_widget_get_theme_node called on the widget [0x564832d5ac90 StIcon:last-child first-child] which is not in the stage. Okt 31 10:32:07 r-thinktop gnome-shell[7044]: g_signal_handler_disconnect: assertion 'handler_id > 0' failed Okt 31 10:33:05 r-thinktop gnome-shell[7044]: _cogl_buffer_fini: assertion '!(buffer->flags & COGL_BUFFER_FLAG_MAPPED)' failed Okt 31 10:36:26 r-thinktop gnome-terminal-[1459]: Allocating size to GtkScrollbar 0x555ada6242e0 without calling gtk_widget_get_preferred_width/height(). How does the code know the size to allocate? Okt 31 10:37:45 r-thinktop gnome-software[7218]: running refine with refine-flags=require-version,require-update-details,require-provenance,require-icon with failure-flags=fatal-any with timeout=60 on apps */*/* Okt 31 10:37:45 r-thinktop gnome-software[7218]: failed to call gs_plugin_add_updates on fwupd: The name org.freedesktop.fwupd was not provided by any .service files Okt 31 10:37:45 r-thinktop gnome-software[7218]: failed to call gs_plugin_add_updates on fwupd: The name org.freedesktop.fwupd was not provided by any .service files Okt 31 10:37:45 r-thinktop gnome-software[7218]: running get-updates with refine-flags=require-update-details,require-update-severity with timeout=60 on plugin=systemd-updates took 3ms Okt 31 10:37:45 r-thinktop gnome-software[7218]: running get-distro-updates with refine-flags=require-version,require-setup-action,require-update-details,require-upgrade-removed,require-provenance,require-icon w Okt 31 10:37:45 r-thinktop gnome-software[7218]: running get-updates with refine-flags=require-version,require-update-details,require-provenance,require-icon with failure-flags=use-events with timeout=60 on plug Okt 31 10:38:36 r-thinktop gnome-terminal-[1459]: Allocating size to GtkScrollbar 0x555ada6242e0 without calling gtk_widget_get_preferred_width/height(). How does the code know the size to allocate? Okt 31 10:38:41 r-thinktop gnome-terminal-[1459]: Allocating size to GtkScrollbar 0x555ada6242e0 without calling gtk_widget_get_preferred_width/height(). How does the code know the size to allocate? Okt 31 10:38:55 r-thinktop dbus-daemon[6921]: [session uid=1000 pid=6921] Activating service name='org.gnome.Nautilus' requested by ':1.2267' (uid=1000 pid=7044 comm="/usr/bin/gnome-shell ") Okt 31 10:38:55 r-thinktop dbus-daemon[6921]: [session uid=1000 pid=6921] Successfully activated service 'org.gnome.Nautilus' Okt 31 10:38:55 r-thinktop dbus-daemon[722]: [system] Activating via systemd: service name='org.freedesktop.hostname1' unit='dbus-org.freedesktop.hostname1.service' requested by ':1.1171' (uid=1000 pid=20280 com Okt 31 10:38:55 r-thinktop systemd[1]: Attaching egress BPF program to cgroup /sys/fs/cgroup/unified/system.slice/systemd-hostnamed.service failed: Invalid argument Okt 31 10:38:55 r-thinktop systemd[1]: Starting Hostname Service... Okt 31 10:38:56 r-thinktop dbus-daemon[722]: [system] Successfully activated service 'org.freedesktop.hostname1' Okt 31 10:38:56 r-thinktop systemd[1]: Started Hostname Service. Okt 31 10:39:01 r-thinktop gnome-terminal-[1459]: Allocating size to GtkScrollbar 0x555ada0cfdf0 without calling gtk_widget_get_preferred_width/height(). How does the code know the size to allocate?
Is the version information in the bug correct (that is, you are using 3.26.x)? If you say that restarting fixes it, does that mean that you are using the X11 session and not wayland? The issue does sound like bug 763246, but that's on wayland and supposed to be fixed since 3.24 ...
Yes, I am on 3.26: $ apt-cache policy gnome-shell gnome-shell: Installed: 3.26.1-3 And yes, I am on X11. Sorry I forgot to mention that. (Also, restarting is not a thing any more on wayland? Ouch. That's an extremely useful work-around for various issues.)
(In reply to Ralf from comment #2) > (Also, restarting is not a thing any more on wayland? Ouch. That's an > extremely useful work-around for various issues.) Applications usually don't deal with the display server going away and just crash. On wayland, that display server is gnome-shell, so restarting it would have the same effect as restarting Xorg has in the X11 session - all your apps go down, if not the session as a whole.
I have experienced this two more times. Both times, I have been using either VirtualBox or virt-manager when this happened. So, it looks like it is related to grabbing as well?
When working with VirtualBox, I am seeing this bug happen pretty frequently -- several times a day.
Actually, I have now also seen this happen twice when no virtual machine application has been running.
Actually I think this is a bug in dash-to-panel: It sometimes goes into "drag'n'drop state" and then stops forwarding events to applications. See https://github.com/home-sweet-gnome/dash-to-panel/issues/433.
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version, then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new ticket at https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/ Thank you for your understanding and your help.