Policies annotated with enterprise_only in the schema will only be allowed to run on ESR or on pre-release channels (for testing)
MozReview-Commit-ID: 4tF8t1ozyVp
Also creates the runOncePerModification helper function in Policies.jsm and fixes a minor bug in the runOnce helper function also in Policies.jsm
MozReview-Commit-ID: HDgMmhHI1D0
This includes simplifiying the startup process, migrating to a new
pref namespace, renaming files, and updating references to the code.
MozReview-Commit-ID: A2cYpsjCOAE
This includes simplifiying the startup process, migrating to a new
pref namespace, renaming files, and updating references to the code.
MozReview-Commit-ID: A2cYpsjCOAE
The Block parameters for the InstallAddons policy doesn't make sense because the addons install process has two behaviors:
- Allow
- Ask
So a website that is not explictly in the allow list will always ask for permission before installing an addon. If a sysadmin wants to fully block addon install they can use a different policy.
Similarly, for Popups it's the same thing. There is a conceptually valid use case in that someone can change the _default_ behavior to always allow popups, and then the Block list becomes the allow exceptions to Ask. But that's a corner case that we don't need to support now, since allowing popups globally on the web is a pretty crazy choice.
MozReview-Commit-ID: EzclfLNDgUo
Set pref datareporting.healthreport.uploadEnabled=false during mochitests
and set pref toolkit.telemetry.server to a dummy server during reftests
(uploadEnabled was already false for reftest and the telemetry server was
already set for mochitests - now these prefs are consistent).
Some mochitests failed with this change; they are updated to
set datareporting.healthreport.uploadEnabled where required.
A top-level array (i.e., if a policy directly requires an array) won't be affected by this problem, because if the array is missing, that means that that policy is not present, so it will be ignored.
However, this can affect an array that is expected inside another object, for more complex policy types (like the popups permission which accepts both an 'allow' and a 'block' array of URLs.
In the future, we should implement the 'required' property as defined by the JSON-Schema standard, but there's not a strong use case for it yet, so let's do the simple solution for now
MozReview-Commit-ID: 4MTBTsPYlX8
Some tests do a sanity check for features at the beginning. This works fine for a single test, and also from one test to another which are usually activating different policies. But this fails when the same test runs more than once, because the engine was left at the end in a state where that same policy was active.
Note that this does not cover all the clean-up that a test must do to properly run more than once. For example, locked prefs are left locked, because the engine does support reversing all the policy code that ran. We might add more auto-reversal support in the future, but for now it's up to each test.
MozReview-Commit-ID: KZ2LeKFTC0A
