Funkcionalnosć tutoho sydła so přez wothladowanske dźěła wobmjezuje, kotrež maja waše dožiwjenje polěpšić. Jeli nastawk waš problem njerozrisuje a chceće prašenje stajić, wobroćće so na naše zhromodźenstwo pomocy, kotrež na to čaka, wam na @FirefoxSupport na Twitter a /r/firefox na Reddit pomhać.

Pomoc přepytać

Hladajće so wobšudstwa pomocy. Njenamołwimy was ženje, telefonowe čisło zawołać, SMS pósłać abo wosobinske informacije přeradźić. Prošu zdźělće podhladnu aktiwitu z pomocu nastajenja „Znjewužiwanje zdźělić“.

Dalše informacije

Firefox binds to absolute add-on paths, why?

  • 6 wotmołwy
  • 0 ma tutón problem
  • 7 napohladow
  • Poslednja wotmołwa wot tbphotb837

more options

I tried to create a default Windows profile with pre-configured app settings, including FF. I created a temporary user, logged in, installed FF and configured it, also installed some add-ons (first of all, ublock origin). Then I logged out, logged as an administrator and moved the temporary user profile to the default profile location (c:\Users\Temp -> c:\Users\Default), and then reset its NTFS permissions. This almost always works for all applications, including Google Chrome. I created a new user and logged in, opened FF. The settings were applied, but the extensions did NOT work, and even the buttons on the toolbar looked like empty squares. At the same time, the add-ons were present in the list of add-ons in settings, although without icons. It helped to turn off and turn on all the add-ons one by one, manually.

After some research, I realized that FF binds its settings to absolute paths to add-on files (*.xpi), specifically in the $profile/extensions.json and $profile/addonStartup.json.lz4 files. Google Chrome, for example, doesn't do anything simular, like the vast majority of applications. Removing these files from the profile will cause all add-ons to be "reinstalled" on first launch and set to a disabled status.

An easier way to reproduce the problem: 1. Run firefox -profile d:\temp\profile1 2. Install some extensions. 3. Rename profile1 folder to profile2. 4. Run firefox -profile d:\temp\profile2 5. Got it!

For what purposes does firefox bind to absolute add-on paths, and how can this problem be solved? P.S. I know about portable firefox from PortableApps.com, but I don't want to use a third-party loader for my tasks.

I tried to create a default Windows profile with pre-configured app settings, including FF. I created a temporary user, logged in, installed FF and configured it, also installed some add-ons (first of all, ublock origin). Then I logged out, logged as an administrator and moved the temporary user profile to the default profile location (c:\Users\Temp -> c:\Users\Default), and then reset its NTFS permissions. This almost always works for all applications, including Google Chrome. I created a new user and logged in, opened FF. The settings were applied, but the extensions did NOT work, and even the buttons on the toolbar looked like empty squares. At the same time, the add-ons were present in the list of add-ons in settings, although without icons. It helped to turn off and turn on all the add-ons one by one, manually. After some research, I realized that FF binds its settings to absolute paths to add-on files (*.xpi), specifically in the $profile/extensions.json and $profile/addonStartup.json.lz4 files. Google Chrome, for example, doesn't do anything simular, like the vast majority of applications. Removing these files from the profile will cause all add-ons to be "reinstalled" on first launch and set to a disabled status. An easier way to reproduce the problem: 1. Run firefox -profile d:\temp\profile1 2. Install some extensions. 3. Rename profile1 folder to profile2. 4. Run firefox -profile d:\temp\profile2 5. Got it! For what purposes does firefox bind to absolute add-on paths, and how can this problem be solved? P.S. I know about portable firefox from PortableApps.com, but I don't want to use a third-party loader for my tasks.
Připowěsnjene fota wobrazowki

Wubrane rozrisanje

I'd suggest you creating a new bug about it, with a reference to these bugs and an additional note that paths are not being recomputed.

Tutu wotmołwu w konteksće čitać 👍 0

Wšě wotmołwy (6)

more options

Wužitny?

more options

The bug is several years old, will it ever be fixed? Why prescribe absolute paths for add-ons at all? A a lot of programs can be expanded with addons, most of them can use relative paths. Chrome does. Many people have encountered this problem, but for some reason it has not yet been fixed, despite the fact that the solution should be very simple. Is there some objective reason?

And do I understand correctly that at the moment the only way is to either use a third-party loader or write your own script?

Wužitny?

more options

Yes, for me it looks like an architectural bug. I don't know whether they going to fix it, as "it seems that the addons mechanism knows how to recompute the JSON file and its paths in the event that the absolute paths do not match."

Wužitny?

more options

TyDraniu said

Yes, for me it looks like an architectural bug. I don't know whether they going to fix it, as "it seems that the addons mechanism knows how to recompute the JSON file and its paths in the event that the absolute paths do not match."

But the problem is precisely that it does not recompute the paths?

Wužitny?

more options

Wubrane rozrisanje

I'd suggest you creating a new bug about it, with a reference to these bugs and an additional note that paths are not being recomputed.

Wužitny?

more options

Wužitny?

Stajće prašenje

Dyrbiće so pola swojeho konta přizjewić, zo byšće na přinoški wotmołwił. Prošu stajće nowe prašenje, jeli hišće wužiwarske konto nimaće.