Bug 77037 - Gnome-Shell Navigation Error
Summary: Gnome-Shell Navigation Error
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/DRI/i965 (show other bugs)
Version: 10.0
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Ian Romanick
QA Contact: Intel 3D Bugs Mailing List
Depends on:
Reported: 2014-04-04 04:34 UTC by Justin Brown
Modified: 2016-02-02 20:47 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:

dmidecode from affected system (8.19 KB, text/plain)
2014-05-19 16:05 UTC, Justin Brown
dmidecode from affected system - Asus H87i-Plus system (17.86 KB, text/plain)
2014-06-04 10:54 UTC, Karel Mácha

Note You need to log in before you can comment on or make changes to this bug.
Description Justin Brown 2014-04-04 04:34:10 UTC
I've been experiencing this problem for nearly a year and haven't had any luck resolving it. I know this sounds like a Gnome problem, but it only occurs when using Intel graphics. 


This occurs exclusively on a HD Graphics 4600 (i7-4770) system. I have tried everything from various single monitor configurations to my usual triple-monitor configuration (1920x1080, 1920x1200, and 2560x1440) and even tried various display connectors. There has not been a discernible difference in the error rate between all of the configurations. Currently, the system has 512MiB of memory assigned to the GPU.


When using HD Graphics 4600 (i7-4770) regardless of monitor configuration, I constantly have the following problem in Gnome (3.8-3.12) on Fedora (versions 19 and 20). Every 5-10 minutes, I will lose the ability to click on any item outside of the active window. The mouse cursor moves around fine, but I can't interact with anything else. No overview mode, no ability to click to focus on anything else. The keyboard and mouse continue to work in the active application. Interestingly, I can alt+tab to another program, and use input devices there. 


If I switch from Gnome on VT1 to any other VT, even for a fraction of a second, and back again then everything returns to normal 95% of the time. (Very rarely, do I have to do it twice.)


There aren't any useful log messages, but the following does appear when this problem occurs. 

[2149:2149:0225/193020:ERROR:browser_main_loop.cc(234)] Gdk: IA__gdk_window_get_events: assertion 'GDK_IS_WINDOW (window)' failed
[2149:2149:0225/193020:ERROR:browser_main_loop.cc(234)] GLib-GObject: g_object_ref: assertion 'G_IS_OBJECT (object)' failed
[2149:2149:0225/193020:ERROR:browser_main_loop.cc(234)] GLib-GObject: g_object_unref: assertion 'G_IS_OBJECT (object)' failed
[2149:2149:0225/193022:ERROR:browser_main_loop.cc(234)] Gdk: IA__gdk_window_get_events: assertion 'GDK_IS_WINDOW (window)' failed
[2149:2149:0225/193022:ERROR:browser_main_loop.cc(234)] GLib-GObject: g_object_ref: assertion 'G_IS_OBJECT (object)' failed
[2149:2149:0225/193023:ERROR:browser_main_loop.cc(234)] GLib-GObject: g_object_unref: assertion 'G_IS_OBJECT (object)' failed
[2149:2149:0225/193023:ERROR:browser_main_loop.cc(234)] Gdk: IA__gdk_window_get_events: assertion 'GDK_IS_WINDOW (window)' failed
[2149:2149:0225/193023:ERROR:browser_main_loop.cc(234)] GLib-GObject: g_object_ref: assertion 'G_IS_OBJECT (object)' failed
[2149:2149:0225/193023:ERROR:browser_main_loop.cc(234)] GLib-GObject: g_object_unref: assertion 'G_IS_OBJECT (object)' failed
[2149:2149:0225/193023:ERROR:browser_main_loop.cc(234)] Gdk: IA__gdk_window_get_events: assertion 'GDK_IS_WINDOW (window)' failed
[2149:2149:0225/193023:ERROR:browser_main_loop.cc(234)] GLib-GObject: g_object_ref: assertion 'G_IS_OBJECT (object)' failed
[2149:2149:0225/193023:ERROR:browser_main_loop.cc(234)] GLib-GObject: g_object_unref: assertion 'G_IS_OBJECT (object)' failed
Gjs-Message: JS LOG: pushModal: invocation of begin_modal failed

Upon the VT switch trick, there's no recovery messages.


I use a variety of Intel HD Graphics systems and have never experienced this problem. They include a laptop with 4400 (i7-4600U), 4000 (i7-3520M), and 3000 (i5-2500K). Fedora, somewhat mysteriously ships a rather old version of xorg-x11-drv-intel (2.21.15). I added Intel's graphics repository (https://download.01.org/gfx/fedora/20/) for Fedora, which includes (2.99.907), but the problem still occurred at the same frequency. 

I've temporary added a Nvidia 210 graphics card using the nouveau driver to this system, and have not experienced the problem in over 6 hours of testing. 


I come away extremely confused. This is such a strange problem to have on one specific GPU.

My gut tells me that it has to be something with Xorg since a switch to a VT immediately fixes it. Unfortunately, Xorg doesn't log any messages when this behavior occurs. 

I'd like to submit more information if anyone can think of additional things to test or debugging options to use.
Comment 1 Karel Mácha 2014-05-12 18:13:04 UTC
Any news on that ? I am suffering from this issue too. It happnes on Fedora 20 with Gnome Shell 3.10-3.12. I can move the mouse cursor around and activities button/the left-upper edge of the gnome shell displays those ripples when I move the cursor over. But I am not able to open the overview, or click the activities button, the user menu also shows no reaction. ALt+F2 or windows keysdoes do not raise any reaction from the system. The window, which was active before the incident reacts on mouse and keyboard.

As long as I switch to another tty and back everything is Ok again. When this problem occurs, I see the following messages in the journal, when I move the cursor over the activities button:

js-Message: JS LOG: pushModal: invocation of begin_modal failed

My computer is equipped with an Intel Core i3 Haswell CPU with Intel HD4600 graphics.
Comment 2 Justin Brown 2014-05-17 17:32:11 UTC
Updating to Intel graphics release 1.0.5 (May 14th) seems to have resolved the problem. https://01.org/linuxgraphics/downloads
Comment 3 Karel Mácha 2014-05-18 22:18:03 UTC
My issues are caused by the wireless Logitech devices being managed by the solaar application.

NO wireless mouse and keyboard, although solaar is running - no problems.
Using Performance Mx and K400 with disabled solaar - no problems.
The freezes appear short after I run solaar when an Unifying Logitech USB receiver is pluged in.
Comment 4 Kenneth Graunke 2014-05-19 01:23:21 UTC
Closing since things apparently work for both reporters.
Comment 5 Karel Mácha 2014-05-19 10:22:31 UTC
I am sorry, but how is this "working" for me ? The only solution for me is a workaround - not using an application managing my wireless Logitech deices.

This bug is not cause by the applictaion itself - as I stated before.
ALso this bug is not caused by the devices itsef.
Comment 6 Justin Brown 2014-05-19 16:04:49 UTC
I apparently jumped the gun on comment #2. The latest Intel graphics release seems to improve the problem a little (maybe 10-15%), but it still occurs. 

I've had a brief correspondence with Karel, and it does seem to be related to the Logitech wireless receiver. I switched from a Logitech Performance MX to a standard USB mouse, and this problem does not occur.

The weird part is that I use this exact same model of mouse (and Monoprice USB keyboard) at work with a HD Graphics 4400, and I have *never* had this problem. I also bring this laptop home, and connect the keyboard and Logitech mouse from my desktop to my 4400 laptop. The problem never occurs. 

There has to be some interaction between the Logitech USB receiver and, umm, something in the graphics stack with certain hardware. Due to the lack of any useful log messages, I'm at a loss to come up with any idea on how to resolve this. 


Karel, could you tell me some more about your hardware? Does this happen on multiple systems? 

My hardware is:

Asrock Z87E-ITX
Integrated Broadcom 4352 (using Broadcom proprietary wl driver)

Full hardware info attached.
Comment 7 Justin Brown 2014-05-19 16:05:18 UTC
Created attachment 99345 [details]
dmidecode from affected system
Comment 8 Justin Brown 2014-05-27 18:02:44 UTC
After additional testing, this problem only occurs when using the Logitech wireless receiver for the Performance MX mouse. Interestingly, this only occurs on one of my Haswell systems. Switching to another mouse makes the problem go away.
Comment 9 Karel Mácha 2014-06-04 10:54:24 UTC
Created attachment 100394 [details]
dmidecode from affected system - Asus H87i-Plus system
Comment 10 Karel Mácha 2014-06-04 10:55:31 UTC
This bug still affects me, even after recent Gnome 3.12.2 updates and Intel-video-drivers updates. It is caused by the Logitech Mouse. I found several other people affected by this weird issue accros the internet, see https://bbs.archlinux.org/viewtopic.php?pid=1418243#p1418243 or https://github.com/pwr/Solaar/issues/163.

I am using Solaar - utility allowing extra settings (usually not available through the standard Linux system configuration). The above described behavior appears right after I launch solaar. I was forced to disable Solaar at startup.

I am running Haswell based system with asus h87i-plus mainboard. I also attached the dmidecode from affected system.
Comment 11 David Juran 2015-08-09 11:58:02 UTC
For the record, this happens on my fedora 21 machine using a radeon card (and drivers).
Comment 12 Justin Brown 2015-08-11 02:01:39 UTC
The Asus Z87e-itx that I had before eventually died. I replaced it ~6 months ago with a Asus Z97e-itx using the exact same processor and memory. The Gnome-Shell problem continued to occur without abatement. 

I resolved this problem a couple of months ago -- by purchasing a refurbished Performance MX (exact same model) mouse (that makes 3 that I own: 1 original desktop, 1 for work, and 1 replacement). The mouse was starting to behave poorly in Windows 7 becoming slightly unresponsive once every hour or so (note: this bad behavior in Windows was in the past 2 months, not when this problem originally occurred). 

Anyways, I got tired dealing with the mouse and decided to purchase a different model. I ended up purchasing a refurbished unit, and it's worked for over 2 months without this issue cropping up.

As far as I'm concerned, this seems to be caused by the mouse as that was the only plausible piece of hardware that wasn't replaced. Furthermore, the issue was immediately resolved by replacing it with a different Performance MX.

The physical condition of the original mouse was quite good. It didn't have any signs of damage or looseness. The plastic end of the USB receiver did wiggle a bit, and that was likely where my problem was. It's entirely speculation on my part, but it seems like some sort of communication failure (or faulty transmission) could be the problem, and replacement with properly working hardware is the best solution.

Does switching to a different mouse (or possibly even keyboard) resolve the issue for you guys?
Comment 13 Chris Henry 2015-08-15 13:31:44 UTC
Hi just to add I have this problem on a Toshiba laptop running Fedora 22. Nvidea graphics so not related to Intel. Common thing is I have just started to run a Logitech wireless mouse. Thanks for the heads up I will try a different mouse and report back.
Comment 14 Felix Kaiser 2015-10-10 16:49:48 UTC
I have a Thinkpad T430s (Intel HD4000), and a Logitech mouse, and have been using both for years without issue. I'm on Fedora 22 and use GNOME.

My left mouse button just stopped working.

It shouldn't be a mechanical or transmission issue, as Justin implied, because the mouse buttons on the laptop stopped working at the same time.

I restarted gnome-shell, and the new GNOME would output the following every time I left-clicked: "Gjs-Message: JS LOG: pushModal: invocation of begin_modal failed"

When I removed and reinserted the Logitech receiver everything went back to normal.
Comment 15 Matt Turner 2015-10-10 17:28:55 UTC
This sounds like a GNOME/input bug. Why does anyone believe the Intel graphics drivers are to blame?

Someone affected, please file a bug at https://bugzilla.gnome.org/ and feel free to add a link here for others to follow. Marking as NOTOURBUG.
Comment 16 Patrik Dufresne 2016-02-02 15:28:05 UTC
I found this post searching for "Gjs-Message: JS LOG: pushModal: invocation of begin_modal failed" on google. I find it very curious, because I do have the exact same mouse: Performance MX. I had it for a week.

I think it safe to consider the problem is related to the mouse and not intel graphics since I have a Nvidia graphic card.

Since this bug it old, I'm wondering how did you fix the issue. Did you replace the mouse? got an RMA? or fix the software.

I'm running Gnome 3.14.1. Debian Jessie 8, x86_64.
Lenovo ThinkPad T530
Performance MX Firmware: 15.01.B0062, Bootloader : 02.11
Comment 17 Felix Kaiser 2016-02-02 17:27:03 UTC
I haven't had the problem for months now, and I'm still using the same receiver and mouse every day all day. So it probably got fixed by some update (there was a Fedora major upgrade (Fedora 22 to Fedora 23) since my last post).

Did you try reconnecting the Logitech receiver (as a workaround)? That worked for me.

Versions of everything:

- gnome-shell 3.18.3 as packaged by Fedora 23. Oh and I'm using Wayland now.

- Thinkpad T430s with Intel graphics

- Logitech Hardware:

  Device path  : /dev/hidraw0
  USB id       : 046d:c52b
  Serial       : (removed)
    Firmware   : 12.01.B0019
    Bootloader : 02.14
  Has 1 paired device(s) out of a maximum of 6.
  Notifications: wireless, software present (0x000900)
  Device activity counters: 1=173

  1: Performance Mouse MX
     Codename     : Performance MX
     Kind         : mouse
     Wireless PID : 101A
     Protocol     : HID++ 1.0
     Polling rate : 8 ms (125Hz)
     Serial number: (removed)
          Firmware: 15.01.B0062
        Bootloader: 02.11
             Other: 00.09
     The power switch is located on the base.
     Notifications: (none).
     Battery: full, discharging.
Comment 18 Patrik Dufresne 2016-02-02 20:24:09 UTC
Ok, so it suggest the problem was not hardware but software related. I'm running the latest Debian version so it's hard to get newer version. But my kernel is old (3.16.7-ckt20-1+deb8u3). I may try to install a more recent version from debian backport.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.