After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 751335 - gnome shell stops working with message "pushModal: invocation of begin_modal failed"
gnome shell stops working with message "pushModal: invocation of begin_modal ...
Status: RESOLVED OBSOLETE
Product: gnome-shell
Classification: Core
Component: general
3.16.x
Other Linux
: Normal major
: ---
Assigned To: gnome-shell-maint
gnome-shell-maint
Depends on:
Blocks:
 
 
Reported: 2015-06-22 16:02 UTC by Maciej (Matthew) Piechotka
Modified: 2021-07-05 14:40 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Journalctl after using Ctrl+Alt+F1 (12.68 KB, text/plain)
2020-10-08 11:22 UTC, Pawel Wodkowski
Details

Description Maciej (Matthew) Piechotka 2015-06-22 16:02:39 UTC
gnome-shell periodically stops working - no response to most mouse inputs (hot corner gives animation but not change into overlay). The only indication of failure is message "Gjs-Message: JS LOG: pushModal: invocation of begin_modal failed" on stdout. I could not find more problems in journalctl.
Comment 1 Jasper St. Pierre (not reading bugmail) 2015-06-22 19:58:22 UTC
That means that some other application took an X11 grab. There's not much I can tell you other than to find the application that did that and figure out what's going on.
Comment 2 l300lvl 2015-06-23 01:52:47 UTC
this is a known bug when using the Overview on Startup or alternate Jump to Overview extension. I was never wise enough to determine why or what we are doing wrong to cause this, but alas it happens depending on how you use the extension. Some talk can be found here, but we are both clueless:

https://github.com/simonthechipmunk/jumptooverview/issues/1

i dont know if you have installed these or anything similair, but just though id mention that some weird things can make it happen...
Comment 3 Maciej (Matthew) Piechotka 2015-06-23 16:51:47 UTC
(In reply to Jasper St. Pierre from comment #1)
> That means that some other application took an X11 grab. There's not much I
> can tell you other than to find the application that did that and figure out
> what's going on.

Hmm.

 - During one repro the only other application running was firefox so the options are limited.
 - Restart of gnome-shell (from tty1 or if gnome-temrminal had focus at the time of bug) should not fix the problem as far as I understand as the offending application would still hold the lock - but it does here.

PS. I don't have any extensions installed.
Comment 4 Jasper St. Pierre (not reading bugmail) 2015-06-23 17:07:42 UTC
Unfortunately, debugging tools on X11 are severely limited -- there is no application which can tell you who took the grab. Are you able to reproduce it often?
Comment 5 Maciej (Matthew) Piechotka 2015-06-25 02:53:34 UTC
(In reply to Jasper St. Pierre from comment #4)
> Unfortunately, debugging tools on X11 are severely limited -- there is no
> application which can tell you who took the grab. Are you able to reproduce
> it often?

I reproduced it multiple times over the weekend but not since then. It might be due to usage patters on workdays/weekends (or amount of things I do during workdays on my own computer).
Comment 6 satellitgo 2015-08-10 23:58:17 UTC
I see this in efi boot f23 Alpha RC-2 workstation x86_64 installed to HD
may be related to ff google callendar pop up event alerts..?
Total system freezes up  have to cold boot to recover.
Comment 7 Michael Catanzaro 2016-08-24 13:07:58 UTC
(In reply to Jasper St. Pierre (not reading bugmail) from comment #1)
> That means that some other application took an X11 grab. There's not much I
> can tell you other than to find the application that did that and figure out
> what's going on.

This happens to me every few days. Today it happened with Epiphany, GNOME Terminal, gedit, Boxes, and System Settings open.

Surely the shell should be robust to this; applications should not be able to break the desktop....
Comment 8 Ray Strode [halfline] 2016-08-24 17:35:34 UTC
it's a limitation of X that applications can break the desktop like that.  Wayland fixes it.

Anyway, I think Daniel Stone added the ability to print grab clients a while back.  digging a little, what you have to do is:

$ gsettings set org.gnome.desktop.input-sources xkb-options "['grab:debug']"

then hit ctrl-alt-F11 and grab info will be sent to the journal.  You'll still have to use xwininfo or xlsclients or something to match up the client ids.
Comment 9 Maciej (Matthew) Piechotka 2017-05-25 18:58:50 UTC
(In reply to Ray Strode [halfline] from comment #8)
> it's a limitation of X that applications can break the desktop like that. 
> Wayland fixes it.
> 
> Anyway, I think Daniel Stone added the ability to print grab clients a while
> back.  digging a little, what you have to do is:
> 
> $ gsettings set org.gnome.desktop.input-sources xkb-options "['grab:debug']"
> 
> then hit ctrl-alt-F11 and grab info will be sent to the journal.  You'll
> still have to use xwininfo or xlsclients or something to match up the client
> ids.

I cannot find anything like that in journal. Any hints on what I should look for?
Comment 10 Ray Strode [halfline] 2018-05-18 19:14:58 UTC
sorry just noticed your question a year later.  

The message is something like

Printing all currently active device grabs:
Active grab 0xc00lbad (xi2) on device 'Virtual core pointer' (2)
End list of active device grabs

should be in the X log.
Comment 11 André Klapper 2019-09-28 20:20:35 UTC
Maciej: Is this still an issue? Or can this be closed as RESOLVED OBSOLETE?
Comment 12 gima+bugzilla-gnome 2019-12-20 10:58:30 UTC
(In reply to André Klapper from comment #11)
> Maciej: Is this still an issue? Or can this be closed as RESOLVED OBSOLETE?

This is still a problem and has been driving me nuts over the last month or so. I'm probably motivated enough to try and retrieve more information out of this (to help debug this) in case someone could point to me how.

------------------------------------------------------------------------------
MY THOUGHTS:

If I'd have to wager a guess..:

-> I'd say the bug exists in something related to Window Manager
(in case that's responsible for managing window focus)

-> It's probably not gnome-shell related
.. because I'm running Cinnamon

-> It's common to GNOME Desktop Environment and Cinnamon Desktop Environment, because the bug has been reported here
.. and since the bug was reported over 4 years ago, it's probably something that's not changed in all this time AND is shared code between these two projects.


------------------------------------------------------------------------------
THE BUG:

Occasionally mouse clicks stop being sent to the window that's active. They either seem to be lost/ignored, or are sent to the wrong window (which I observed by selecting text in a terminal and text was instead being selected in another terminal window).

Keyboard works correctly, and can change window focus by Alt+Tab.

------------------------------------------------------------------------------
WHAT I TRIED:

Running `cinnamon --replace & disown` and it didn't help. The only result was, that I was given some output, such as multiple lines of:
> Cjs-Message: 12:17:06.726: JS LOG: pushModal: invocation of begin_modal failed
and
> (cinnamon:50760): Cjs-WARNING **: 12:27:40.742: JS ERROR: TypeError: b is null
Panel.prototype._updatePanelVisibility@/usr/share/cinnamon/js/ui/panel.js:3481:44

The stupidest thing is, that after playing around without mouse for a while, the problem disappeared by itself! (about 5 to 10 minutes)


------------------------------------------------------------------------------
MY SYSTEM SPECS:

  Operating System: Arch Linux
            Kernel: Linux 4.19.89-1-lts
      Architecture: x86-64

local/cinnamon 4.4.4-1
local/cinnamon-desktop 4.4.1-1
local/cinnamon-session 4.4.0-1
local/cinnamon-settings-daemon 4.4.0-2
local/cjs 4.2.0-1
local/muffin 4.4.1-1
Comment 13 Dmitry 2020-05-28 09:14:41 UTC
Have recently faced the same issue on Ubuntu 18.04. It occurs rather frequently, sometimes, within ten minutes. Previously, it has never occurred. Same message is printed in the logs. 

Upgrade to Ubuntu 20.04, which ships GNOME Shell 3.36.2, did not help.

There is an immediate workaround, documented on the unix stack exchange/ Switching to login screen (Ctrl+Alt+F1) and back to the main (Ctrl+Alt+F2) helps: https://unix.stackexchange.com/questions/502315/gnome-partially-stops-responding-to-mouse-keyboard
Comment 14 Pawel Wodkowski 2020-10-08 11:19:19 UTC
I'm also facing this issue on Ubuntu 18.04. When I used Dmitry workaround journalctl spitted number of stack traces and asserts, but everything started to work.

I'm attaching this log.
Comment 15 Pawel Wodkowski 2020-10-08 11:22:09 UTC
Created attachment 374289 [details]
Journalctl after using Ctrl+Alt+F1
Comment 16 Dmitry 2020-11-07 12:01:35 UTC
I think it might have been something wrong with my wireless mouse, because it also caused some issues with the window manager on Macs. I have a set of Microsoft keyboard and mouse, and when I used the mouse on Mac, it caused some issues with highlighting of menu items. When I replaced it with a different wireless mouse (but kept the keyboard), the issue was gone. 

As I used the same keyboard and mouse on Linux, I suspect this issue was also somehow caused by the mouse. If you face this issue, consider checking if it reproduces with a different mouse.

Even if this hypothesis is correct, I wonder what can go wrong with a mouse so that it appears to work but breaks window managers on different OSes, and how to debug it. It used to work perfectly.
Comment 17 GNOME Infrastructure Team 2021-07-05 14:40:53 UTC
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.