GNOME Bugzilla – Bug 724813
Window List Extension Doesn't Load (3.11.90)
Last modified: 2014-02-20 21:16:52 UTC
I installed the latest 3.11.90 version of the window-list extension from http://koji.fedoraproject.org/koji/buildinfo?buildID=499492 (atop the 3.12.x preview COPR repository at http://copr.fedoraproject.org/coprs/rhughes/f20-gnome-3-12/) I then enabled the extension workaround with gsettings set org.gnome.shell disable-extension-version-validation true Most extensions worked, but the window-list extension (the one I rely upon most heavily) failed. The messages below were found in journald: Feb 20 12:47:32 sgallagh520.linux.gallagherhome.com gnome-session[2012]: (gnome-shell:2296): Gjs-WARNING **: JS ERROR: Exception in method call: LaunchExtensionPrefs: Error: can't convert ["extension:///window-list@gnome-shell-extensions.gcampax.github.com"] to an integer Feb 20 12:47:32 sgallagh520.linux.gallagherhome.com gnome-session[2012]: GnomeShellExtensions<.LaunchExtensionPrefs@resource:///org/gnome/shell/ui/shellDBus.js:375 Feb 20 12:47:32 sgallagh520.linux.gallagherhome.com gnome-session[2012]: wrapper@resource:///org/gnome/gjs/modules/lang.js:169 Feb 20 12:47:32 sgallagh520.linux.gallagherhome.com gnome-session[2012]: _handleMethodCall@resource:///org/gnome/gjs/modules/overrides/Gio.js:261 Feb 20 12:47:32 sgallagh520.linux.gallagherhome.com gnome-session[2012]: _wrapJSObject/<@resource:///org/gnome/gjs/modules/overrides/Gio.js:331
(In reply to comment #0) > Feb 20 12:47:32 sgallagh520.linux.gallagherhome.com gnome-session[2012]: > (gnome-shell:2296): Gjs-WARNING **: JS ERROR: Exception in method call: > LaunchExtensionPrefs: Error: can't convert > ["extension:///window-list@gnome-shell-extensions.gcampax.github.com"] to an > integer That's fallout from https://git.gnome.org/browse/gnome-shell/commit?id=5dedc5d8ba4f0e6fa; we should probably just revert the part that removes the URLs parameter. However that shouldn't prevent the extension itself from working (and it works for me in both normal and classic mode on master, which should be close enough to 3.11.90 at this point ...) (In reply to comment #0) > I then enabled the extension workaround with > gsettings set org.gnome.shell disable-extension-version-validation true Does that mean that there is a version mismatch in the repository? (I apparently can't figure out how to get a packagelist in the copr interface). If that's the case, then yeah - the window-list extension used to use API that was removed, disabling the version check won't help with that (but updating should :-) )
I am not sure if the validation change mattered in this particular case. The gnome-shell-extensions were not (at the time of my upgrade) available in the COPR repository. I tried with the version validation disabled, which gave me several of the extensions back (but not this one) and then went ahead and grabbed the Rawhide package instead, which still didn't work. So I filed this bug. I'm not running Classic mode (I wonder if it *would* work in that situation). I'm running a hybrid/chimera of Classic and standard with a number of extensions. Full information about my setup can be found here: http://sgallagh.wordpress.com/2013/06/27/one-week-with-gnome-3-classic-twenty-eight-days-later/
(In reply to comment #2) > I am not sure if the validation change mattered in this particular case. The > gnome-shell-extensions were not (at the time of my upgrade) available in the > COPR repository. I tried with the version validation disabled, which gave me > several of the extensions back (but not this one) Yeah, this extension required some actual fixes rather than a simple version bump. > and then went ahead and grabbed the Rawhide package instead, which still > didn't work. So I filed this bug. Just to make sure - the rawhide version is already at 3.11.90? If yes, did you restart the shell before confirming that it wasn't working? > I'm not running Classic mode (I wonder if it *would* work in that situation). Nah, it really shouldn't make a difference (unless somehow the style breaks horribly)
(In reply to comment #3) > (In reply to comment #2) > > I am not sure if the validation change mattered in this particular case. The > > gnome-shell-extensions were not (at the time of my upgrade) available in the > > COPR repository. I tried with the version validation disabled, which gave me > > several of the extensions back (but not this one) > > Yeah, this extension required some actual fixes rather than a simple version > bump. > > > > and then went ahead and grabbed the Rawhide package instead, which still > > didn't work. So I filed this bug. > > Just to make sure - the rawhide version is already at 3.11.90? If yes, did you > restart the shell before confirming that it wasn't working? > The Rawhide version was built today and is what I linked above. I restarted the shell via alt-f2 and 'r'. I haven't tried fully logging out yet, but I'd expect that to have been sufficient.
(In reply to comment #4) > The Rawhide version was built today and is what I linked above. I restarted the > shell via alt-f2 and 'r'. I haven't tried fully logging out yet, but I'd expect > that to have been sufficient. Indeed. I'll see if I can reproduce the issue with an updated rawhide ...
Created attachment 269825 [details] [review] shell-app: Add back uri parameter The extension system does use it to open preferences of a particular extension, so add it back. This partly reverts commit 5dedc5d8ba4f0e6fac8e4c62e558a0b30eb6f0f1.
Created attachment 269826 [details] [review] shellDBus: Fix LaunchExtensionPreferences() Commit 5dedc5d8ba4f0e6fa removed "unused" functionality which was still used by that method. Launch it via GAppInfo instead, which still supports passing URIs.
(In reply to comment #0) > Feb 20 12:47:32 sgallagh520.linux.gallagherhome.com gnome-session[2012]: > (gnome-shell:2296): Gjs-WARNING **: JS ERROR: Exception in method call: > LaunchExtensionPrefs: Error: can't convert > ["extension:///window-list@gnome-shell-extensions.gcampax.github.com"] to an > integer Either one of the attached patches fixes this (unrelated) issue.
Review of attachment 269826 [details] [review]: Yep.
Attachment 269826 [details] pushed as 2d24536 - shellDBus: Fix LaunchExtensionPreferences() OK, let's pick this one ...
Did you install it manually at some point? i.e do you have one sitting around in ~/.local/share/gnome-shell/extensions ? If yes deleete it to make sure the system one is used.
(In reply to comment #11) > Did you install it manually at some point? i.e do you have one sitting around > in ~/.local/share/gnome-shell/extensions ? If yes deleete it to make sure the > system one is used. Ah ha! Looks like that was exactly the problem. I think at some point in the nebulous past, I updated a few of these directly from extensions.gnome.org (because the Fedora packages weren't updated yet). Looks like those got prioritized over the system copy. It would be ideal if the metadata.json was required to include a version field so the shell could pick whichever version was newer (personal or system). But I realize that's its own can of worms. Thanks for the help. This looks like it's working now.
Great!