extension woes, remote profile [solved: network.file.disable_unc_paths]

[RealDrGordonFreeman]

Problem: Extensions can be downloaded and installed. Extensions will not function or show their configuration pages. Fresh profile on FF 65.0.1 (Windows AMD64), latest ghacks. Occurs with any extension. Update: Cause of problem found, see below. Currently searching for solution. Update: Solution found, see below.

Example of error when attempting to access uBlock origin extension config options:

Access to the file was denied
The file at moz-extension://dd6f4e2e-66af-4aa8-bbc7-f59690d323a0/dashboard.html is not readable.
It may have been removed, moved, or file permissions may be preventing access.

Console messages:

NS_ERROR_FILE_ACCESS_DENIED ExtensionContent.jsm:157

That ExtensionContent.jsm @ view-source:resource://gre/modules/ExtensionContent.jsm points to line 157:

defaultConstructor(url) { let promise = ChromeUtils.compileScript(url, this.options); promise.then(script => { promise.script = script; }); return promise; }

This extension access error seems somewhat related to: #227

Cause: This problem occurs only if the profile is stored remotely on a shared folder network path and is caused by the user.js setting network.file.disable_unc_paths; true.

Solution: Set network.file.disable_unc_paths; to false.

[RealDrGordonFreeman]

attn @gorhill

[crssi]

I can't reproduced... also fresh profile on FF 65.0.1 (Windows x64) with latest ghacks. Installed uBO and it works just fine.

But there is a glitch on FF 65.0.1, fresh not altered profile (without user.js):
Open about:addons.
Open AMO in another tab.
Install any WE.
Return to about:addons tab.
The new WE installed has blue progress bar and cannot be clicked.
Reload of 'about:addons page makes everything fine again.

[RealDrGordonFreeman]

Okay. Found the cause, which was actually to do with network paths. Now updating original post.

Cause: This problem occurs only if the profile is stored remotely on a shared folder network path.

[crssi]

And can you reproduce with a fresh profile without user.js?

[RealDrGordonFreeman]

It works perfectly without user.js so I am assuming user.js has locked down access to remote network paths.

To clarify:

• If the profile is stored locally, everything works properly with user.js enabled.
• If the profile is stored remotely, everything works properly without user.js enabled.
• If the profile is stored remotely, extensions do not work with user.js enabled.

So perhaps a setting that is preventing a remotely stored add-on from being accessed might be the problem, as the error page does throw out the originally described 'access denied' error.

[Thorin-Oakenpants]

/* 2660: lock down allowed extension directories
 * [SETUP-CHROME] This will break extensions that do not use the default XPI directories
 * [1] https://mike.kaply.com/2012/02/21/understanding-add-on-scopes/
 * [1] archived: https://archive.is/DYjAM ***/
user_pref("extensions.enabledScopes", 1); // [HIDDEN PREF]
user_pref("extensions.autoDisableScopes", 15);
``

[RealDrGordonFreeman]

Have been tinkering with various combinations of the specific settings suggested by the Son of Thrain, but no success yet.

Update: The default FF config is 0 for enabledScopes and 15 for autoDisableScopes. Adjusting to the 0 and 15 default, and various other combos, did not correct the error. So could it perhaps be another setting?

Update: It seems those settings have more to do with the install part of the extension rather than it's functionality. Not sure.

More info: https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/Distribution_options/Add-ons_in_the_enterprise#Firefox_settings

Update: Okay. Solution found. It was the restriction of network paths found in the setting -

network.file.disable_unc_paths; true

when changed to false, the extension worked.

Now updating original post with solution.

Also, perhaps a note should be included in the script for that setting which explains that if used with a remotely stored profile on a network path this setting should be changed to false.

[Thorin-Oakenpants]

Thanks for the trubleshooting. It wasn't clear from the first few posts that the profile was using UNC, but yeah, obviously that (pref) would screw things up, but doesn't exactly stick out

I'll see what @earthlng says about adding a [SETUP-CHROME] tag. I would expect this sort of thing in an enterprise, and users should be able to troubleshoot it themselves (we don't want to overdo it on the setup tags or it defeats the power of having them)

bump @earthlng

[earthlng]

IMO [SETUP-CHROME] should be reserved for things that a lot of people might want to change.
In this case I think a one-liner would be better, something like "breaks extension pages for profiles on network shares"

[RealDrGordonFreeman]

@earthlng so long as there is some brief somewhere to prevent grey hairs, fists upon desks, grinding of teeth, clenching of jaws, or any other bouts of frustration. Perhaps the Son of Thrain will agree.

[Thorin-Oakenpants]

The problem is what to add in the one line so that a trouble shooter would find it - and I can't predict what a user will search for, unless I use a setup tag. We have 11 of them, 1 more won't hurt :slipperyslope: :natiionalemergency: :wall:

[Thorin-Oakenpants]

Without testing it, I'm not sure if the breakage is just the extension pages. i.e is the actual extension and/or extension IDB/localstorage etc created (maybe Firefox as the parent process isn't restricted). But IMO, the actual extension is broken, since it can't read it's settings - depends on the extension I guess. I'm not even sure if it's IDB or localStorage. No need to test anything, I'll just make the info a bit more generic