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 704509 - Can't install extensions from via iceweasel in debian wheezy
Can't install extensions from via iceweasel in debian wh...
Product: gnome-shell
Classification: Core
Component: extensions
Other Linux
: Normal normal
: ---
Assigned To: gnome-shell-maint
Depends on:
Reported: 2013-07-18 22:36 UTC by r.3
Modified: 2021-07-05 14:43 UTC
See Also:
GNOME target: ---
GNOME version: ---

Description r.3 2013-07-18 22:36:25 UTC
On debian wheezy, with iceweasel 10.0.12.
If I go to, and try to install an extension, the on/off slider moves to "on", there is a prompt if I want to install the extension, I answer yes, but then nothing happens, and nothing is created in ~/.local/share/gnome-shell/extensions. Reloading the page shows the on/off slider in "off" position.

If I install an extension by hand in ~/.local/share/gnome-shell/extensions it works. I have unzip installed. My proxy is configured in both the navigator and gnome settings. Nothing is created in .xsession_errors, nor in looking glass errors. It does not appear in looking glass extension panel.

I think that (what?) tries to install it to /usr/share/gnome-shell/extensions, where there already are several extensions. The problem is that this directory is "root" access, I do not have permissions on it (computer at work).

Could you solve the problem, or help me identify what component is responsible for it ? My guess is that the faulty thing is the "gnome shell integration" plugin, but not sure at all.

Comment 1 r.3 2013-07-18 22:48:42 UTC
I tried with epiphany, same problem. So this might not be linked with the browser, more with the distribution. 

why does it try to save it in "/usr/share/gnome-shell/extensions", and not in "~/.local/share/gnome-shell/extensions/" ?
Comment 2 r.3 2013-07-22 13:48:48 UTC
Actually, in debian, the gnome-shell's "user extension directory" is configured to be /usr/share/gnome-shell/extensions/. As only root can access this, and I do not have the root access, installation through the plugin would never succeed.

What would be cool is in gnome-shell/js/ui/extensionsSystem.js, function gotExtensionZipFile, to :
- try unzip in the ExtensionUtils.userExtensionsDir (eg /usr/share/gnome-shell/extensions/ in debian)
- if it does not work, try the local dir (eg ~/.local/gnome-shell/extensions/)
Comment 3 r.3 2013-07-22 14:00:44 UTC
in newer version of Gnome-shell (3.8.3), the concerned file is gnome-shell/js/ui/extensionDownloader.js, the code to improve is in _onInstallButtonPressed that shall try to call a second time gotExtensionZipFile if failed with the first directory taken from global.userdatadir
Comment 4 Jasper St. Pierre (not reading bugmail) 2013-07-22 18:12:23 UTC
(In reply to comment #2)
> Actually, in debian, the gnome-shell's "user extension directory" is configured
> to be /usr/share/gnome-shell/extensions/. As only root can access this, and I
> do not have the root access, installation through the plugin would never
> succeed.

We write to that directory a lot, not just for extensions, so that's Debian's packaging bug.
Comment 5 r.3 2013-07-22 19:19:57 UTC
thanks for the information.

In order to solve this bug, what option do debian people need to change to package correctly gnome-shell regarding this ? can they reconfigure gnome-shell extension directory to be :
~/.local/share/gnome-shell/extensions (user access)
and not :
/usr/share/gnome-shell/extensions (root access) ?

if they do so, how can gnome shell :
- use the local directory ~/.local/share/gnome-shell/extensions
- but still read the directory /usr/share/gnome-shell/extensions that contains packaged gnome-shell extensions?

I'll report this to debian.

Comment 6 Jasper St. Pierre (not reading bugmail) 2013-07-22 19:27:26 UTC
We use the standard environment variable $XDG_DATA_HOME to get the user data directory at runtime. Make sure nothing is setting that.
Comment 7 Gautier Pelloux-Prayer 2016-12-02 13:49:31 UTC
As of today it is still a bug. And I confirm that XDG_DATA_HOME is still not set under Debian stretch/sid, but adding this line in /etc/profile solves the problem after restarting the session:

export XDG_DATA_HOME="$HOME/.local/share"

So after setting that, extensions are installed nicely.

Some thoughts:

1) There should be an error in $HOME/.xsession-errors when this happens - permission denied should be logged.
2) Why gnome-shell does not fallback to $GNOME/.local/share as the official specification states[1]?

>  $XDG_DATA_HOME defines the base directory relative to which user specific data files should be stored. If $XDG_DATA_HOME is either not set or empty, a default equal to $HOME/.local/share should be used. 

3) Why debian does not set XDG_DATA_HOME? This is outside of this bug scope though.

Comment 8 Gautier Pelloux-Prayer 2017-01-17 09:27:45 UTC
Edit: actually this was not the reason of extensions failing to install for me. It was for other reasons (see Bug 776940). It was mainly missing system deps. Gnome-shell actually does fallback to $HOME/.local/share.
Comment 9 Florian Müllner 2017-11-25 06:33:28 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance:
Comment 10 Florian Müllner 2017-11-25 08:56:48 UTC
Sorry for the noise, I "found" a bug in the migration script:
Comment 11 GNOME Infrastructure Team 2021-07-05 14:43:40 UTC
GNOME is going to shut down in favor of
As part of that, we are mass-closing older open tickets in
which have not seen updates for a longer time (resources are unfortunately
quite limited so not every ticket can get handled).

If you can still reproduce the situation described in this ticket in a recent
and supported software version, then please follow
and create a new ticket at

Thank you for your understanding and your help.