1811214 - Add-ons `normal_installed` through policies.json from local URLs and disabled by user are re-enabled after each restart

Status: RESOLVED FIXED

(Thunderbird :: Add-Ons: General, defect, P3)

Description

[Raphaël Halimi]

Steps to reproduce:

I prepared a policies.json file to automatically install add-ons in a corporate environment.

Most of them have the "normal_installed" setting which is supposed to allow the user to disable it. Indeed it can be disabled, but it's re-enabled after each restart.

It partly defeats the point of having two distinct settings for add-ons ("normal_installed" and "force_installed"), since the disabled add-on is re-enabled after each restart, it's almost the same as being forbidden to disable it.

Note 1 : It only happens for add-ons installed from local URLs ("file:///"). I can't have the add-ons installed from remote URLs because users are not supposed to have access to the Internet from Thunderbird (they are behind a proxy, which is configured in Firefox, but not in Thunderbird). For testing purposes I configured the proxy in Thunderbird and specified an external URL in the policies.json file, and disabled the add-on : it stays disabled after a restart (as it should).

Note 2 : It seems to be a regression from Firefox, since it doesn't display this behavior. Whether the add-ons are installed from a local URL or a remote one, if the user disables them, they stay disabled across restarts (as they should).

Comment 1

[Thomas D. (:thomas8)]

Thanks. Confirming based on reporter's elaborate report.

Richard, is there a FF bug we can port?

Comment 2

[John Bieling (:TbSync)]

That file:// urls are handled differently is explicitly enforced in m-c code:
https://searchfox.org/comm-central/source/mail/components/enterprisepolicies/Policies.sys.mjs#1534

You can verify that behavior with any firefox add-on: Download it (instead of installing it from AMO). Then install it from file, disable it and install it again. It is enabled again.

Comment 3

[John Bieling (:TbSync)]

I forgot to mention: We cloned their code and the link in my last comment points to our version. Here are both:
https://searchfox.org/comm-central/search?q=%21addon.sourceURI.schemeIs%28%22file%22%29&path=&case=false&regexp=false

So we could divert from FF behaviour, but do we want that? I do not know the answer to that ...

Comment 4

[Raphaël Halimi]

(In reply to John Bieling (:TbSync) from comment #2)

That file:// urls are handled differently is explicitly enforced in m-c code:
https://searchfox.org/comm-central/source/mail/components/enterprisepolicies/Policies.sys.mjs#1534

You can verify that behavior with any firefox add-on: Download it (instead of installing it from AMO). Then install it from file, disable it and install it again. It is enabled again.

No. I checked, in Firefox, when policy mandates that add-ons are installed, even from local URLs, if the user disables one, it stays disabled after a restart.

Also, I forgot to mention that in my policy file I use the new ExtensionSettings directive, and not the old Extensions one.

Comment 5

[John Bieling (:TbSync)]

Ok, that is new then. I will need a few days to verify and check this.

Comment 6

[John Bieling (:TbSync)]

Attachment: Bug 1811214 - Upstream synchronization - port Bug 1715965. r=#thunderbird-reviewers

We missed an upstream synchronization, which added an early exit
to the install routine of add-ons installed through enterprise policies,
keeping their enabled state.

Comment 7

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/84627aac377f
Upstream synchronization - port Bug 1715965. r=aleca