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 690653 - Load extensions asynchronously breaks extensionPrefs
Load extensions asynchronously breaks extensionPrefs
Status: RESOLVED DUPLICATE of bug 694858
Product: gnome-shell
Classification: Core
Component: general
3.7.x
Other Linux
: Normal normal
: ---
Assigned To: gnome-shell-maint
gnome-shell-maint
Depends on:
Blocks:
 
 
Reported: 2012-12-22 21:57 UTC by Norman Smith
Modified: 2013-02-28 14:48 UTC
See Also:
GNOME target: ---
GNOME version: 3.7/3.8


Attachments
adds a synchronous scan to the ExtensionFinder class (2.59 KB, patch)
2012-12-22 21:57 UTC, Norman Smith
none Details | Review

Description Norman Smith 2012-12-22 21:57:23 UTC
Created attachment 232133 [details] [review]
adds a synchronous scan to the ExtensionFinder class

commit 6b40c3974d55c52e67c066da59febc34c6d7c92e
extensionUtils: Load extensions asynchronously

The above commit breaks extensionPrefs/main.js.
When the gnome-shell-extension-prefs is executed with 
an extension url or uuid as an argument the extensions 
are not loaded before _extensionAvailable() is called in 
_onCommandLine in main.js.

The attached patch adds a synchronous scan to the
ExtensionFinder class in extensionUtils for use by
callers who need the extensions populated without delay.
Comment 1 Florian Müllner 2013-02-28 14:48:45 UTC
Sorry for ignoring the patch for that long - I don't think there is anything wrong with using synchronous IO in this case, but the duplication with FileUtils is not too nice. We just landed an alternative fix in bug 694858, which changes the extension-prefs tool instead to wait until extensions are actually loaded.

Again, sorry for not coming back to this earlier (and thanks for the patch!), please don't let this stop you from contributing in the future.

*** This bug has been marked as a duplicate of bug 694858 ***