UI experiences delay when menu / tooltip disappears

Bug #1681290 reported by SimonWerner
14
This bug affects 3 people
Affects Status Importance Assigned to Milestone
gnome-shell (Ubuntu)
Confirmed
Undecided
Unassigned

Bug Description

Sometimes the system will not respond to mouse clicks or keypresses. This appears to happen when I hold the mouse over an item and a pop-up tooltip appears, or when I click on a menu. I believe it happens when the tooltip/menu is set to disappear.

Steps to reproduce are:
 1) Select a menu item
 2) Click outside the menu
 3) The click won't register for around 7 or 8 seconds. No other keypresses register immediately but will occur around 7 seconds later.

This occurs in GNOME, GNOME applications and also for non-GNOME applications such as Firefox and Chrome.

lsb_release -rd:

Description: Ubuntu Zesty Zapus (development branch)
Release: 17.04

apt-cache policy gnome-session:

gnome-session:
  Installed: 3.24.0-0ubuntu1
  Candidate: 3.24.0-0ubuntu1
  Version table:
 *** 3.24.0-0ubuntu1 500
        500 http://nz.archive.ubuntu.com/ubuntu zesty/universe amd64 Packages
        100 /var/lib/dpkg/status

ProblemType: Bug
DistroRelease: Ubuntu 17.04
Package: gnome-shell 3.24.0-0ubuntu2
ProcVersionSignature: Ubuntu 4.10.0-19.21-generic 4.10.8
Uname: Linux 4.10.0-19-generic x86_64
ApportVersion: 2.20.4-0ubuntu3
Architecture: amd64
CurrentDesktop: GNOME
Date: Mon Apr 10 11:39:40 2017
DisplayManager: gdm3
EcryptfsInUse: Yes
InstallationDate: Installed on 2016-05-12 (332 days ago)
InstallationMedia: Ubuntu-GNOME 16.04 LTS "Xenial Xerus" - Release amd64 (20160421)
ProcEnviron:
 LANGUAGE=en_NZ:en
 PATH=(custom, no user)
 XDG_RUNTIME_DIR=<set>
 LANG=en_NZ.UTF-8
 SHELL=/bin/bash
SourcePackage: gnome-shell
UpgradeStatus: Upgraded to zesty on 2017-04-08 (1 days ago)

Revision history for this message
SimonWerner (simonwerner) wrote :
Revision history for this message
SimonWerner (simonwerner) wrote :

I raised this bug and found that if I deleted all my GNOME settings, the problem disappeared.

Revision history for this message
Daniel van Vugt (vanvugt) wrote :

Sounds like it might be another grabs-related issue.

Click on the above tag "noclick" to see related bugs.

tags: added: noclick
Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in gnome-shell (Ubuntu):
status: New → Confirmed
Revision history for this message
Daniel van Vugt (vanvugt) wrote :

I think this is close enough to bug 1181666 to be a duplicate. Plus comment #2 implies this bug should close anyway.

Revision history for this message
Matt (mangoduck) wrote :

I'm having this problem years later in Gnome 3.36.3, Ubuntu 20.04.1. It also happened in 19.x. I don't think it's a duplicate of #1181666 because that states some interaction is still possible. In this issue, the whole ui is stuck. Windows, shell, clock, video that's playing, everything but the mouse cursor. Done a lot of searching for a newer ticket but none is a dead ringer like this.

The problem develops a while (hours?) after a fresh start and seems to get more exaggerated as time passes. On a larger scope, a fresh install is free of this problem at first, and then it develops after days/weeks of normal use. Had a hunch that it started after installing a particular package, but I can't remember what it was for the life of me. Clutter? Wxwidgets? Just a hunch anyway.

Closing of menus, tooltips, and to some degree open/save dialogs are delayed up to many seconds. This makes interacting with file managers and web pages infuriating. I have interface sounds on (smooth soundset, which includes menu actions) and noticed that opening a window menu and scrubbing the mouse over the other top level items (file, edit, etc.) still produces sound while this is going on, and the total wait time until the display unsticks is compounded with every one. ***To me this says it's not "no click" so much as "can't see".*** After zigging back and forth I can be waiting a minute or more, meanwhile I can still hear music playing, etc.

Regarding comment 2, I've not yet tried deleting my gnome settings because I didn't want to gum things up, but regardless I'm not sure how that implies this should be closed or is invalid. Gnome shouldn't be doing things to that file that interfere with its own operation, right? Again, this is from everyday use, and I've not been messing around in things.

Revision history for this message
Matt (mangoduck) wrote :

Forgot to mention, menus in gnome-shell itself (top bar, dock, and other panels) do not suffer from this delay. They close immediately. This ticket is associated with gnome-shell, but the way the original author describes it, the shell isn't affected for them either: "This occurs in GNOME, GNOME applications and also for non-GNOME applications such as Firefox and Chrome."

Revision history for this message
Daniel van Vugt (vanvugt) wrote :

This bug is closed. Please use bug 1181666 instead.

Revision history for this message
Matt (mangoduck) wrote :

Bug 1181666 does not at all describe the issue we are having here.

Revision history for this message
Daniel van Vugt (vanvugt) wrote :

If you have a different issue then please open a new bug of your own by running:

  ubuntu-bug gnome-shell

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.