gnome-shell-extension-gsconnect icon indicating copy to clipboard operation
gnome-shell-extension-gsconnect copied to clipboard

Opening prefs causes all other extensions to not be able to open prefs

Open blennster opened this issue 3 years ago • 2 comments

Describe the bug

When pressing the cogs icon in gnome-extensions-app and closing, I am not able to open it again. I cannot open any other prefs either. Stdout says

Gjs-Message: 13:02:07.338: JS LOG: Ignored exception from dbus method: Gio.IOErrorEnum: GDBus.Error:org.gnome.gjs.JSError.Error: Already showing a prefs dialog

Steps To Reproduce:

  1. Open gnome-extesions-app
  2. Click on the cog on GSConnect
  3. Close window

Expected behavior

It should be possible to open the prefs again for extensions.

System Details (please complete the following information):

  • GSConnect version: 47
  • Installed from: GNOME Extensions Website
  • GNOME/Shell version: 41
  • Distro/Release: EndeavourOS

blennster avatar Dec 01 '21 12:12 blennster

Thanks for reporting with the relevant error message.

I expect that the method we use to close the unused wrapper window, before opening our true preferences window, is no longer working due to some internal change in GTK4. The relevant lines are here:

https://github.com/GSConnect/gnome-shell-extension-gsconnect/blob/396ae953f965c5bbbc2a6e354c78b858b623f98c/src/prefs.js#L16-L22

Rather than an idle source, a more reliable approach might be connecting to GtkWidget::map.

andyholmes avatar Dec 02 '21 16:12 andyholmes

still a issue

aspizu avatar Sep 14 '22 17:09 aspizu

Can confirm this issue is still present on GNOME 42.4, built from git.

astudentinearth avatar Sep 23 '22 14:09 astudentinearth

Issue still persist on Gnome 45.3 Wayland

clevrf0x avatar Jan 13 '24 18:01 clevrf0x

Issue still persist on Gnome 45.3 Wayland

I'm not able to reproduce, on Fedora 39 with gnome-shell-45.3-1.fc39 and GSConnect 56.

If I go into gnome-extensions-app:

  1. I can click "Settings" for GSConnect, and the window comes up.
  2. I can then click "Settings" for Appindicator and KStatusNotifierItem Support 57 and get its preferences window.
  3. Or click "Settings" for OpenWeather 122, for its preferences.

If I close the GSConnect preferences window, I can then still do any of the previous, or:

  1. Click "Settings" for User Themes 54, and get its preferences window.
  2. Click "Settings" for Background Logo (no version number displayed), and... you get the idea.

I can somewhat reproduce the pathology of losing access to preferences, but not with GSConnect.

If I have Desktop Icons NG (DING) 67 installed but not enabled (as is typically the case), and I click "Settings" for it, not only will its settings not come up, but no other settings windows will either, with the "Already showing a prefs dialog" message being logged. (If DING is actually enabled, it will instead display its settings.)

If I go into d-spy and find the Process ID for the org.gnome.Shell.Extensions backend (or I use ps -ef | grep Shell.Extensions to find it), and I kill $thatpid to "reboot" the d-bus interface, normal preferences access is restored.

This is starting to feel more like a bug in the GNOME Extensions application/backend, that GSConnect is sometimes getting caught up in.

ferdnyc avatar Feb 20 '24 14:02 ferdnyc

https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/4825 indicates the issue might also be dependent on Wayland vs. Xorg, but if so I would expect it to affect Xorg users, not Wayland users.

Regardless, I've filed https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/7435 for issues with the Extensions app's prefs dialog detection.

ferdnyc avatar Feb 25 '24 14:02 ferdnyc

@clevrf0x (or anyone else still experiencing this issue), please open a new issue with full steps to reproduce, details on your environment, GSConnect version, etc.

By all indications from https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3209 (opened by a GNOME dev in response to https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/7435), GSConnect version 56 should be doing the right thing to prevent the problems reported here, so if users are still encountering this it may be a different issue (even if it manifests in the same way).

ferdnyc avatar Feb 27 '24 19:02 ferdnyc

@ferdnyc I can't seem to replicate the issue anymore. Looks like it is fixed.

clevrf0x avatar Feb 27 '24 20:02 clevrf0x