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 782187 - extensionSystem: Force the reload of files upon reloading
extensionSystem: Force the reload of files upon reloading
Status: RESOLVED WONTFIX
Product: gnome-shell
Classification: Core
Component: extensions
unspecified
Other All
: Normal normal
: ---
Assigned To: gnome-shell-maint
gnome-shell-maint
Depends on:
Blocks:
 
 
Reported: 2017-05-04 21:29 UTC by Jonh Wendell
Modified: 2018-07-11 16:03 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
extensionSystem: Force the reload of files upon reloading (1.31 KB, patch)
2017-05-04 21:29 UTC, Jonh Wendell
needs-work Details | Review

Description Jonh Wendell 2017-05-04 21:29:14 UTC
Instruct gjs to delete the import so that next time we refer
to the extension files gjs will re-read them instead of using
a cached property.

This fixes the following scenario: Suppose you are an extension
developer and want to fix a bug on your extension. Then:

1) You open an text editor and make some changes to your extension
2) In a terminal, you run: gnome-shell-extension-tool -r <extension-id>
3) Your changes are not visible; In fact, they were not reloaded.

With this patch, step 2 above would work as expected, thus making
the life of an extension developer a lot easier :)
Comment 1 Jonh Wendell 2017-05-04 21:29:19 UTC
Created attachment 351121 [details] [review]
extensionSystem: Force the reload of files upon reloading

Instruct gjs to delete the import so that next time we refer
to the extension files gjs will re-read them instead of using
a cached property.

This fixes the following scenario: Suppose you are an extension
developer and want to fix a bug on your extension. Then:

1) You open an text editor and make some changes to your extension
2) In a terminal, you run: gnome-shell-extension-tool -r <extension-id>
3) Your changes are not visible; In fact, they were not reloaded.

With this patch, step 2 above would work as expected, thus making
the life of an extension developer a lot easier :)
Comment 2 Jonh Wendell 2017-05-04 21:31:52 UTC
This will effectively work when the gjs patch gets merged: https://bugzilla.gnome.org/show_bug.cgi?id=782186

(Currently it doesn't hurt, i.e., it doesn't throw an error, it just doesn't work)
Comment 3 Florian Müllner 2017-05-09 17:19:58 UTC
Review of attachment 351121 [details] [review]:

Marking as needs-work as of https://bugzilla.gnome.org/show_bug.cgi?id=782186#c3
Comment 4 Reto Kaiser 2017-09-02 18:57:40 UTC
So it's not possible to delete keys from `imports`.
Would it be a feasible approach to use a new key when re-initializing the extension, so instead of `imports[extension.uuid]` use `imports[extension.uuid + Math.random()]`?

I'm wondering what happens when an extension is upgraded. Is the new code also only activated when gnome-shell is restarted?
Comment 5 Norman Smith 2018-01-03 17:50:17 UTC
RE- Comment 4
"I'm wondering what happens when an extension is upgraded. Is the new code also only activated when gnome-shell is restarted?"

I just tested with the ego site. The new code is not active until the gnome-shell is restarted.  Having to restart when working on an extension under Wayland is a bit of a hassle.  A thread on the Jan 2018 gnome-shell-list "How to reload extension with modified code" prompted my comment here.
Comment 6 Florian Müllner 2018-07-11 16:03:59 UTC
I'll close this bug for now, as there's currently no idea how the required support in gjs could be implemented. There's also the related issue that extensions nowadays are able to contain GObject subclasses, for which reloading would require unregistering a GType first.

My hunch thus is that it is probably best to give up on the idea that extensions can be updated at runtime, and it may even make sense to handle them as offline updated in Software rather than as "applications".

This shouldn't be a major issues for extension users (at least as long as they use GNOME Software and get extension updates as part of updating the system). It's quite obviously different for extension developers, where reloading an extension frequently without logging out from the running session is essential. The easiest workaround right now is using the Xorg session for extension development, which isn't great. However we should be able to cover that use case in a clean and less intrusive way by leveraging mutter's nested mode, possibly even having it integrated into GNOME Builder.