Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Removing the extension doesn't remove DBus file and others. #1269

Open
rastersoft opened this issue Mar 6, 2022 · 7 comments · May be fixed by #1270
Open

Removing the extension doesn't remove DBus file and others. #1269

rastersoft opened this issue Mar 6, 2022 · 7 comments · May be fixed by #1270
Labels
maybe A feature or change that's not certain to be implemented

Comments

@rastersoft
Copy link

Describe the bug

After uninstalling the extension, the DBus file at ~/.local/share/dbus-1/services remain, and thus the service remains announced in DBus even when there is no code for serving it.

Steps To Reproduce:

  1. install the extension
  2. uninstall the extension
  3. launch d-feet
  4. go to "Session bus"
  5. Search for 'gsconnect'

Expected behavior

No service should be shown. But, instead, the gsconnect service is still announced as "activatable". Of course, any attempt to access it returns an error.
rastersoft added a commit to rastersoft/gnome-shell-extension-gsconnect that referenced this issue Mar 6, 2022
@rastersoft
Remove all files when disabling extension
3bf8d4d 
If the extension is uninstalled, the DBus file and others
remain in the system. This can cause problems to other programs
that interact with GSConnect.

This patch fixes this issue by removing all the files when the
extension is disabled, and recreating them when it is enabled.

Fix GSConnect#1269
@rastersoft rastersoft linked a pull request Mar 6, 2022 that will close this issue
Open
@rastersoft
Copy link
Author

We discovered this doing some tests with an MR for integrating GSConnect with Desktop Icons NG.

https://gitlab.com/rastersoft/desktop-icons-ng/-/merge_requests/216

@andyholmes
Copy link
Collaborator

I'm not really an active maintainer here, so I won't reject or approve this.

My personal thoughts are:

  • I don't think it's a good idea to be doing I/O like this on enable()/disable(), since that happens on every screen lock/unlock and session login/logout
  • Without real-world testing, I'm not convinced this won't cause problems with dbus-broker or excessive churn for any application holding a GAppinfoMonitor

Two options:

  • This should generally be a non-issue as long as the org.freedesktop.DBus.ObjectManager proxy is using Gio.DBusProxyFlags.DO_NOT_AUTO_START during construction and Gio.DBusCallFlags.NO_AUTO_START for any direct calls. Waiting for g-name-owner to be non-null should be an acceptable way to wait for the service to start.
  • For GNOME 42 GSConnect should probably adopt the unlock-dialog session mode, in which case this would be "less bad" since enable()/disable() only get called on login/logout (pretty rare). It should probably be using that session mode anyways...

@rastersoft
Copy link
Author

The big problem is when the extension is uninstalled, because it leaves "dirt" behind. Those files should be deleted. Is there an "uninstall" method for the extensions, called after being disabled and before being removed? If not, it would be a good idea, I think. I think that i could send a patch for that, in fact.

@rastersoft
Copy link
Author

rastersoft commented Mar 7, 2022 •
edited

BTW... what is that "unlock-dialog session mode"? I'm searching in google but can't find info...

@rastersoft
Copy link
Author

Oh, I think that I found something https://gjs.guide/extensions/overview/anatomy.html#metadata-json-required

@rastersoft
Copy link
Author

Ok, I added the "unlock-dialog" mode.

@andyholmes
Copy link
Collaborator

Those files should be deleted. Is there an "uninstall" method for the extensions, called after being disabled and before being removed?

There is no counterpart to the init() hook, like there is with enable()/disable(), probably for a few reasons. The long story short is that there is no good way to do this, because extensions aren't supposed to be applications or install application files like this.

It's possible this could be done by the service itself, since it already watches for the service to be uninstalled, but again some real-world testing would be required to see that this didn't break anything else. GSConnect is already stitched together by a system of duct-tape, bubblegum and twine pulleys so I'm not keen on making that more fragile 🙂

Ok, I added the "unlock-dialog" mode.

Unfortunately the session-modes key won't work until gnome-shell >= 42.0 and as far as I know GSConnect does not yet run on gjs >= 1.71.

@andyholmes andyholmes added the maybe A feature or change that's not certain to be implemented label Aug 3, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
maybe A feature or change that's not certain to be implemented
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Remove all files when disabling extension rastersoft/gnome-shell-extension-gsconnect
2 participants
@rastersoft @andyholmes