1654491 - Absolute paths for Extenstions can break the Extenstions or even the Browser iteself

Status: RESOLVED DUPLICATE of bug 1429838

(WebExtensions :: Untriaged, enhancement)

Description

[david.gittler]

Attachment: Screenshot_1.png

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Firefox/68.0

Steps to reproduce:

I'm running a larger Windows-based terminal-server / VDI farm with support for multiple users, multiple sessions of the same user at the same time, and multiple languages to various users. I want to provide them Firefox 78.0.2 ESR.

The default path for the Firefox-Appdata Folder is C:\Users%username%\AppData\Roaming\Mozilla, which is fine as long as just one User uses that folder at a time. In circumstances where a user is logged in multiple times, he has multiple isolated sessions on the same machine, that share the same filesystem, so also the same profile folder path.
Firefox cannot handle multiple isolated instances of the browser access the same profile, and the 2nd attempt to open the browser fails with an error that the browser is already running, which is fine.

Our attempted solution to this attempt was to move the profile folder around with login and logout scripts, the profile-folder is moved to a session-specific path. I used FSLogix App Masking to emulate this Profile-Folder beeing present at %appdata%\Mozilla to trick the Browser, and in the past I attempted another way without FSLogix too, then I just manipulated the profiles.ini file to link to another location. These approaches work well enough until you run into extensions.

If you load extensions, the browser saves it under the extensions-subfolder of the current profile folder as it should be, but it saves an absolute path of the extension path. These absolute paths I can somehow not even mask with FSLogix to be just C:\Users%username%\AppData\Roaming\Mozilla\Firefox\Profiles......., it actually tells the current path of the temporary profile folder.

If the profile is moved around again, the paths break obviously and extensions fail to load. I would not be too depended on extensions if it wheren't for the language packs - as I said we use multiple languages on the same machine for different users.
The way I accomplish it is by installing the Firefox in our main language (German) and loading the language pack XPI files via Group Policy setting from the official extensions library and requesting the language also via Group Policy on a user-specific basis, which then depends on that language pack extensions.
If the profile is moved around with an language pack installed, in some cases it does not just disable the language pack but also breaks the entire browser and prevents it from starting up. (Looks like Screnshot attached)

Deleting the file addonStartup.json.lz4 repairs the browser profile but unloads all extensions, and these are not loaded automatically again but asks the User to decide in the settings.

Actual results:

Moving around the Firefox Profile in the file system breaks extensions and language packs because it breaks absolute paths to these in the config.
But moving around the Firefox Profile on a day-to-day basis can be nessesacy in some very speifiic installations and should not be a problem.

Expected results:

Extensions which are installed in the extensions-subfolder of the corrensponding profile-folder from the Browser itself should NOT carry absolute paths. It should just say %currentprofilefolder%\extensions\something.xpi in the config, so that it doesn't care where the current profile folder is actually located.

Alternatively it would work by deleting addonStartup.json.lz4 via script if I had a way to tell the browser to load everything in the extensions-folder, no questions asked. But this was removed for a good reason and the first solution would be much better anyway.

Comment 2

[david.gittler]

I developed a workaround and explained it and uploaded it here: https://bugzilla.mozilla.org/show_bug.cgi?id=1429838#c24