GNOME Bugzilla – Bug 763159
Mouse cursor disappears when moved on top of Shell UI
Last modified: 2017-09-24 14:39:56 UTC
In Gnome Shell 3.18.4, the mouse cursor will disappear if moved over any part of the shell, including the top panel, Favorites bar, or any part of the overlay. Version: gnome-shell 3.18.4-1 Distro: Arch Linux
Can you provide steps to reproduce this? Did it start happening after a recent update?
(In reply to Rui Matos from comment #1) > Can you provide steps to reproduce this? Did it start happening after a > recent update? This started happening after updating to gnome-shell 3.18.4. To reproduce it, all I have to do is just move my mouse out of a window to the top panel or Favorites Bar, or lock the screen with GDM. The cursor will only appear if it's in a window or on the desktop. Also, if it's somehow related, Nvidia driver version is 361.28-2.
(In reply to Ed Shockley from comment #2) > This started happening after updating to gnome-shell 3.18.4. To reproduce From which version? Was mutter updated too and which versions? Can you install the previous versions of just these packages and re-verify?
(In reply to Rui Matos from comment #3) > (In reply to Ed Shockley from comment #2) > > This started happening after updating to gnome-shell 3.18.4. To reproduce > > From which version? Was mutter updated too and which versions? Can you > install the previous versions of just these packages and re-verify? Gnome-shell and gnome-shell-extensions were updated from 3.18.3 to 3.18.4. Mutter was also updated to 3.18.3 from 3.18.2. I downgraded the three packages then restarted gnome-shell and the issue did not occur. I then upgraded them again and the bug occurred again.
(In reply to Ed Shockley from comment #4) > Gnome-shell and gnome-shell-extensions were updated from 3.18.3 to 3.18.4. > Mutter was also updated to 3.18.3 from 3.18.2. Do you use extensions? Which ones? Can you try without extensions? > I downgraded the three packages then restarted gnome-shell and the issue did > not occur. I then upgraded them again and the bug occurred again. That's odd as I don't see anything that could have caused this going in between those versions. And indeed I can't reproduce the issue locally.
(In reply to Rui Matos from comment #5) > (In reply to Ed Shockley from comment #4) > > Do you use extensions? Which ones? Can you try without extensions? I just disabled all of my extensions and restarted gnome-shell. Did not resolve the issue. Are there any more system specs that could help? Do you want an output from neofetch?
I also have this issue, and after some trouble shooting, I have pinpointed the issue to having multiple monitors. Deleting monitor.xml & monitor.xml~ from the .config in the home directory will reset the current monitor configuration, but after rebooting, the cursor will reappear. Rearranging my monitors in settings will cause the cursor to disappear again on the next reboot.
(In reply to kerryliu123 from comment #7) > I also have this issue, and after some trouble shooting, I have pinpointed > the issue to having multiple monitors. Deleting monitor.xml & monitor.xml~ > from the .config in the home directory will reset the current monitor > configuration, but after rebooting, the cursor will reappear. Rearranging > my monitors in settings will cause the cursor to disappear again on the next > reboot. This seems to be the problem. Deleting monitor.xml and restarting gnome-shell will fix the issue, but after restoring it and restarting again, the problem persists. Does this help, Rui? I've added my current monitor.xml for reference.
Created attachment 323214 [details] monitors.xml file
I talked to /u/SomeGenericUsername on reddit, he thinks it has something to do with this commit: https://git.gnome.org/browse/mutter/commit/?h=gnome-3-18&id=58d2bd05815a8917460ec7231a1e50ed8cedf19f
Downgraded mutter to 3.18.2-1 from 3.18.3-1 and solved the problem: ``` dvitali ~/Downloads sudo pacman -U mutter-3.18.2-1-x86_64.pkg.tar.xz loading packages... warning: downgrading package mutter (3.18.3-1 => 3.18.2-1) resolving dependencies... looking for conflicting packages... Packages (1) mutter-3.18.2-1 Total Installed Size: 5,09 MiB Net Upgrade Size: 0,00 MiB :: Proceed with installation? [Y/n] Y (1/1) checking keys in keyring [######################] 100% (1/1) checking package integrity [######################] 100% (1/1) loading package files [######################] 100% (1/1) checking for file conflicts [######################] 100% (1/1) checking available disk space [######################] 100% :: Processing package changes... (1/1) downgrading mutter [######################] 100% ```
Created attachment 323316 [details] [review] wayland-pointer: Drop a phony signal disconnect cursor_sprite_prepare_at() is never connected to a MetaCursorTracker signal. -- This is just a drive-by cleanup
Created attachment 323317 [details] [review] Revert "cursor-renderer: do not update cursor if it is out of monitor" On the X11 backend we don't track the pointer position in priv->current_x/y which remain set to zero. That means we never set the clutter stage cursor if point 0,0 isn't covered by any monitor since we return early. Commit 4bebc5e5fa8aade8a96c769bf2365abe0948f6ce introduced this to avoid crashing on the prepare-at handlers when the cursor position doesn't fall inside any monitor area but we can handle that higher up in the stack.
Created attachment 323318 [details] [review] Handle meta_screen_get_monitor_for_point() returning NULL MetaCursorSprite's prepare-at signal can legitimately hand us coordinates that fall outside of any monitor. In that case, the sprite's scale doesn't matter since the cursor won't be shown anyway so we can skip setting it. -- This is the simplest fix for the original crash in bug 756698. We could perhaps re-work it so that we don't need the prepare-at signal in the first place but I couldn't come up with anything that I'd be happy with. The main issue is that only the higher layers know how to set a sprite's scale and OTOH, only the cursor renderer knows when a new scale might be required. Jonas?
Created attachment 323503 [details] [review] [gnome-3-18] wayland-pointer: Drop a phony signal disconnect It needed some manual adjustment to apply against gnome-3-18.
I can confirm that it fixes the bug for me on GNOME 3.18.x / Fedora 23.
Review of attachment 323316 [details] [review]: Right, we we connect the object so it should clean up by itself.
Review of attachment 323317 [details] [review]: Originally I didn't want to do it this way, since we'd be knowingly prepare a cursor with a state that could not be prepared. But since we don't know this state then running as a X11 CM I guess we need let the callees handle it. I also think you should squash this and the next patch into one, so that if anyone who end up bisecting pass this fix will not accidentally hit the crash this patch re-introduces.
Sorry for the multiple comments, the BZ review system was playing tricks on me.
Attachment 323316 [details] pushed as c380f2e - wayland-pointer: Drop a phony signal disconnect Attachment 323318 [details] pushed as 8b801aa - Handle meta_screen_get_monitor_for_point() returning NULL Squashed the patches
*** Bug 763532 has been marked as a duplicate of this bug. ***
*** Bug 763632 has been marked as a duplicate of this bug. ***
*** Bug 746594 has been marked as a duplicate of this bug. ***