Unresponsive top right menu (gnome 3.32)

balvik commented 5 years ago

Linux Distribution version

Antergos (basically Arch linux)

Gnome Shell version

3.32.0

Xorg or Wayland (or both)

Wayland using GDM

Extension version or branch

Built from sources on 22.3.19 evening (master branch after commit 09e97a88f3a4b9efbe40845a16aced09fbe20c07)

Description of the problem

It's almost working again after Gnome upgrade to 3.32 (good job there by the way). However, one (strange) problem remains: enabling the extension causes the Gnome top right menu (not sure what's it's called but I've attached an image) to become unresponsive. The menu items (e.g. "wired connection", "on" for blutooth", "fully charged", etc) don't respond to clicks. Disabling this extension, the menu works normally, enabling it, the menu freezes up again, repeatably.

Screenshot from 2019-03-23 21-46-16

balvik commented 5 years ago

Here's a log from journalctl when I enable the extension, if it's of any help.

Mar 23 22:03:27 jupiter org.gnome.Shell.desktop[4959]: == Stack trace for context 0x55ce38238320 ==
Mar 23 22:03:27 jupiter gnome-shell[4959]: The offending signal was destroy on Gjs_BaseIcon 0x55ce3843d1e0.
Mar 23 22:03:27 jupiter org.gnome.Shell.desktop[4959]: == Stack trace for context 0x55ce38238320 ==
Mar 23 22:03:27 jupiter gnome-shell[4959]: Attempting to call back into JSAPI during the sweeping phase of GC. This is most likely caused by not destroying a Clutter actor or Gtk+ widget with ::destroy signals connected, but can also be caused by using the destroy(), dispose(), or remove() vfuncs. Because it would crash the application, it has been blocked and the JS callback not invoked.
Mar 23 22:03:27 jupiter gnome-shell[4959]: The offending signal was destroy on Gjs_BaseIcon 0x55ce38bb5070.
Mar 23 22:03:27 jupiter gnome-shell[4959]: Attempting to call back into JSAPI during the sweeping phase of GC. This is most likely caused by not destroying a Clutter actor or Gtk+ widget with ::destroy signals connected, but can also be caused by using the destroy(), dispose(), or remove() vfuncs. Because it would crash the application, it has been blocked and the JS callback not invoked.
Mar 23 22:03:27 jupiter gnome-shell[4959]: The offending signal was destroy on Gjs_BaseIcon 0x55ce38285480.
Mar 23 22:03:27 jupiter gnome-shell[4959]: Attempting to call back into JSAPI during the sweeping phase of GC. This is most likely caused by not destroying a Clutter actor or Gtk+ widget with ::destroy signals connected, but can also be caused by using the destroy(), dispose(), or remove() vfuncs. Because it would crash the application, it has been blocked and the JS callback not invoked.
Mar 23 22:03:27 jupiter gnome-shell[4959]: The offending signal was destroy on Gjs_BaseIcon 0x55ce3be31880.
Mar 23 22:03:27 jupiter gnome-shell[4959]: Attempting to call back into JSAPI during the sweeping phase of GC. This is most likely caused by not destroying a Clutter actor or Gtk+ widget with ::destroy signals connected, but can also be caused by using the destroy(), dispose(), or remove() vfuncs. Because it would crash the application, it has been blocked and the JS callback not invoked.
Mar 23 22:03:27 jupiter gnome-shell[4959]: The offending signal was destroy on Gjs_BaseIcon 0x55ce3829d7e0.
Mar 23 22:03:27 jupiter gnome-shell[4959]: Attempting to call back into JSAPI during the sweeping phase of GC. This is most likely caused by not destroying a Clutter actor or Gtk+ widget with ::destroy signals connected, but can also be caused by using the destroy(), dispose(), or remove() vfuncs. Because it would crash the application, it has been blocked and the JS callback not invoked.
Mar 23 22:03:27 jupiter gnome-shell[4959]: The offending signal was destroy on Gjs_BaseIcon 0x55ce3b03afc0.

passingthru67 commented 5 years ago

How do you have WtD configured? I can't tell from the screenshot. I'm wondering if the dock is preventing mouse clicks from passing through it.

Also, would you test again with all other extensions disabled? I recently had an issue where I thought WtD was giving trouble and it turned out to be another extension interfering with WtD functionality. That's just the nature of Gnome Shell extensions.

balvik commented 5 years ago

Just tried disabling all other extensions and enabling only WtD and the problem it still present.

Regarding configuration, the only settings I changed after a fresh installation were:

Show dock on left
switch off the thumbnails (thumbnail tab -> switch off "add captions to workspace thumbnails")
Limiting pressure sense in the Autohide options.
Partial dock, "What should we do with the dock when not dodging windows" = Show partial

balvik commented 5 years ago

Aha! The problem is caused when moving the dock to the left. When on the right, the menu works fine.

passingthru67 commented 5 years ago

Do you have more than one monitor?

balvik commented 5 years ago

Yes, 2 monitors, primary on the right, secondary on the left.

passingthru67 commented 5 years ago

Looks like it may have something to do with multi-monitor setups. I'll have to connect another monitor and test it out.

balvik commented 5 years ago

Yes, after disabling the secondary monitor, the issue disappears.

balvik commented 5 years ago

You know what, I'm gonna close this, I don't think the problem is caused by WtD. I completely removed it and I'm still seeing the problem. It's possible caused by another extension, or more likely it seems to be coming back to this upstream bug of gnome which apparently affects many extensions (not sure if that includes WtD, but certains TopIcon Plus and various forks): Gnome-shell bug

passingthru67 / workspaces-to-dock