You are here

Firefox Developer Edition - Setting a particular preference causes add-on installs to fail

4 posts / 0 new
Last post
Kernel
Offline
Last seen: 3 years 6 days ago
Joined: 2006-10-05 16:26
Firefox Developer Edition - Setting a particular preference causes add-on installs to fail

I'm using Firefox Developer Edition v79, and I've been getting plagued by a particular issue for a while, but only recently found a bug report that clued me into the cause - and it's specific to the portable version only.

Preface:

Firefox prohibits extensions from working on their own site (specifically, addons.mozilla.org). In order to allow extensions to work on this protected site, you have to do the following in about:config:

  1. Clear the contents of "extensions.webextensions.restrictedDomains".
  2. Create/Set "privacy.resistFingerprinting.block_mozAddonManager" to True.

Problem:

However, it turns out that there is a problem - when "privacy.resistFingerprinting.block_mozAddonManager" is set to True, you can't install addons from addons.mozilla.com. They fail with the error "The add-on could not be downloaded because of a connection failure."

You can still manually save the XPI file and install it by pointing the URL bar to the local path - but direct installs from Mozilla's site will not work.

But here's the real issue - this problem ONLY exists in the portable version. In the normal installed version, setting "privacy.resistFingerprinting.block_mozAddonManager" to True doesn't cause the problem with installing extensions.

Is this something that is fixable?

John T. Haller
John T. Haller's picture
Online
Last seen: 23 min 51 sec ago
AdminDeveloperModeratorTranslator
Joined: 2005-11-28 22:21
Likely -profile or cache conflict

The copy of Firefox Developer included in our package is unaltered, so it's unlikely anything due to it being portable. It's likely a conflict with either -profile or having cache disabled, which is an internal issue in Firefox. You can try enabling cache in Firefox Developer Portable to see if that fixes it. If not, try running your locally installed one from the command line with -profile "X:\SomePath\profile" to a temporary profile. It's likely this will also fail.

Sometimes, the impossible can become possible, if you're awesome!

Kernel
Offline
Last seen: 3 years 6 days ago
Joined: 2006-10-05 16:26
Okay, so I tried running the

Okay, so I tried running the locally installed version with the -profile switch - it still worked properly. This did not cause the bug to show up.

As for enabling the cache in the portable version, you didn't specify the exact configuration option to do this. I tried setting "browser.cache.disk.enable" to True, but that did not fix the bug.

So at least for the moment - the only thing distinguishing whether the bug shows up is whether Firefox is the installed version (everything works) or the portable version (bug exists).

John T. Haller
John T. Haller's picture
Online
Last seen: 23 min 51 sec ago
AdminDeveloperModeratorTranslator
Joined: 2005-11-28 22:21
Version and Move

Ok, first make sure you're running the same version both portably and locally. As Dev is a beta, it'll have bugs that may be in one but not the next a couple days later.

If they're the same, try copying the local Firefox Developer folder somewhere else and then run it with -profile from there to see if what you want to do works.

Sometimes, the impossible can become possible, if you're awesome!

Log in or register to post comments