Works as expected here with the UUIDs I tried (both from the command line and gnome-tweak-tool) - if you run gnome-shell-extension-prefs without parameter, does the extension in question have a prefs button?
The UI we have there is a bit confusing, patch coming ...

Created attachment 285568 [details] [review]
extensionPrefs: Improve handling of OutOfDate extensions

Our current UI is horrible in dealing with outdated extensions - all
we do is hide the preference button (if any), giving users no indication
at all that something is not working as expected.
To fix this, don't mess with the visibility of the prefs button and use
sensitivity of both enable switch and prefs button to indicate OutOfDate
extensions.

Created attachment 285569 [details] [review]
extensionSystem: Fix reloading on version-validation changes

The current code only works for enabled extensions, which means
that extensions that were marked OUT_OF_DATA cannot be enabled
without a restart when disabling the version check.
Fix this by reloading all extensions while making sure to only
enable any extensions when we're supposed to.

Florian, why is this in NEEDINFO ?

(In reply to comment #4)
> Florian, why is this in NEEDINFO ?

Because "gnome-shell-extension-prefs <UUID>" works for me.

So I suspect that the regression the bug claims does not exist, but Bastian was trying an outdated extension and our UI is horribly confusing in that case.

Created attachment 285575 [details] [review]
extensionPrefs: Remove version check from extensionAvailable()

It is confusing to treat outdated extensions as if they didn't exist
in some places, but like any other extensions elsewhere. In particular
gnome-tweak-tool still allows to launch prefs for them while making
it clear to users that the extension will not work - opening the
list of installed extensions in that case is unexpected and confusing.
Just remove the version check for now, we will soon follow tweak-tool
and use it to disable the extension switch instead.

Created attachment 285576 [details] [review]
extensionPrefs: Improve handling of OutOfDate extensions

Updated patch to not disable the prefs button - I think gnome-tweak-tool is right, there's really no good reason to disable the prefs when an extension cannot be enabled.

(In reply to comment #1)
> Works as expected here with the UUIDs I tried (both from the command line and
> gnome-tweak-tool) - if you run gnome-shell-extension-prefs without parameter,
> does the extension in question have a prefs button?
> The UI we have there is a bit confusing, patch coming ...

gnome-shell-extension-prefs does its own version check instead of asking the shell if it could support it. My running gnome-shell was 3.13.90, gnome-shell-extension-prefs was that from jhbuild, a 3.13.91... Especially as it was showing the extension as being on.

I've removed regression from the bug title, but it's really not that clear a UI, as you said.

I'd say that's an unsupported configuration, though we could probably make it a bit easier to debug.

So it's basically a (non-offline) update problem - I agree with Jasper that it's not really worth addressing.
Re-titling the bug to make it about the UI issue we should fix.

Review of attachment 285569 [details] [review]:

OUT_OF_DATA in commit message

::: js/ui/extensionSystem.js
@@ +275,3 @@
+    // extensions when allowed by the sessionMode, so
+    // temporarily disable them all
+    enabledExtensions = []

Missing semi

Review of attachment 285575 [details] [review]:

OK.

Review of attachment 285576 [details] [review]:

Sure.

(In reply to comment #10)
> So it's basically a (non-offline) update problem - I agree with Jasper that
> it's not really worth addressing.

I'd like at least some debug output to state that.

(In reply to comment #14)
> (In reply to comment #10)
> > it's not really worth addressing.
> 
> I'd like at least some debug output to state that.

I don't think that's useful - with those patches, the only thing that won't work when we think an extension is out-of-date is the switch to enable/disable it, and we communicate this in the UI by making the switch insensitive. If that is not clear enough, I'd rather add some warning icon to indicate the error state like gnome-tweak-tool instead of odd console messages ("We think extension Foo is outdated, so you cannot enable/disable it"). But then, extension-prefs is hardly the primary way of managing extensions (we don't even have a .desktop file!), so being less complete than Tweak Tool isn't a big issue IMHO (I should probably add that the patches do fix the gnome-tweak-tool case).

Attachment 285569 [details] pushed as 4d64bbc - extensionSystem: Fix reloading on version-validation changes
Attachment 285575 [details] pushed as d209bc6 - extensionPrefs: Remove version check from extensionAvailable()
Attachment 285576 [details] pushed as 593acb9 - extensionPrefs: Improve handling of OutOfDate extensions

I don't think this needs a UI freeze exception, so pushed.

(In reply to comment #15)
> (we don't even have a .desktop file!)

Oh, we actually do - still, it's NoDisplay, so point still stands ...