Not sure if I should post here, ask fedora, or file a bug. I was testing a gnome shell extension I created yesterday and it worked in Fedora 38 VM. Today it does not. Eventually I created a new Fedora 38 VM and created a new interactive gnome shell extension. It is the default code. It doesn’t run either. Even trying to enable window-list shell extension doesn’t work. background-logo is also not running in VM.
Installed Fedora 37 in VM. A new interactive gnome shell extension works fine. window-list can be enabled. background-logo is running by default. I haven’t tried my extension yet.
It seems like Fedora 38 has broken shell-extensions at the moment. My machine is still running shell extension but that might be because I haven’t updated and rebooted recently. Is anyone else seeing this problem.
I was told to check ‘gsettings get org.gnome.shell disable-user-extensions’. It returns true. It must have been false at one point. Did Fedora disable user extensions recently?
No problems here using Fedora 38. Recent updates didn’t change the behaviour of Gnome extensions. Sorry that I can’t provide any further help, but wanted to give feedback that Fedora didn’t disable extensions in general.
I encountered the same thing a few days ago. I have two machines running Fedora 38, and I realized that one wasn’t showing the Fedora logo on any desktop background despite “gsettings set org.fedorahosted.background-logo-extension logo-always-visible true”
Eventually I thought to check “gsettings get org.gnome.shell disable-user-extensions” and it returned true. Setting that to false returned the Fedora logo to my desktop background. I have no idea when or how it was changed, or why it only happened on one of my two machines.
I just experienced the same thing. I had to start the Extensions application and enable extensions again. Extensions were still working before I installed updates yesterday, so likely some update disabled them. I used GNOME Software to install the updates, and it doesn’t seem I can get a list of which packages were updated.
To add that information, I’m usually performing updates using dnf on the commandline. I‘ll try to figure out which updates came in over the last few days.
I got the following response from shell extensions irc channel:
it is set automatically (by a sytemd job) if gnome-shell crashed in the first 60 seconds after initializing extensions
it’s a safety mechanism, so a buggy extension cannot lock out the user forever (because the session crashes on startup)
So in my case I caused it by crashing gnome-shell while testing my extension.
To fix run: gsettings set org.gnome.shell disable-user-extensions false
In my case, I only have the extensions that come with Fedora by default. It looks like (from “dnf list installed | grep extension”): apps-menu, background-logo, common, launch-new-instance, places-menu, window-list. I actually didn’t realize until now that there we so many installed.
It’s possible that I upgraded one machine through GNOME Software and the other through DNF. I use them interchangeably.
gnome-extensions list
gnome-extensions list --enabled
It does occur to me that I don’t know why extensions were disabled on a fresh Fedora 38 install. I didn’t have any broken extensions trying to run on that VM.
As an additional information, you can always use dnf history to see transactions of the packagemanager and get a list of all affected packages by using dnf history info id. I looked up the updates of the last few days and could’t find anything that would breake extensions either.
When a already installed extension is not F38 ready it could crash the system. So i do not know if the system is so smart checking each extension of comparability or just switches of extensions in general.
This could be checked direct after installing in the extension app.
While typing last sentence … probably it is killing all because the extension app has to be updated ?!