We normally validate hashes of XPIs as part of installing experiments.
While a useful security feature, this patch makes that optional. This in
turn makes automated and manual testing easier.
To sync experiment state with the addon manager, we need to start it early when there is a
active experiment.
However, initializing the telemetry experiments system too early can lead to performance
regressions, so we delay the initialization if we don't have an active experiment.
Subsequent patches were running into race conditions and bugs related to
Experiments instance initialization state. This patch plugs the
necessary holes in initialization state management to unblock work.
The fixes are far from robust. There are still race conditions and bugs.
They should probably be addressed later.
The experiments service insists on being in control of experiments.
Before, it wasn't being as assertive as it needed to be: other browser
components could install experiments behind its back. This patch
reasserts the experiments service as king of experiments add-on
management.
We now maintain per-type counts/IDs of each Policy, Experiments, and
ExperimentEntry. The log events for each type are prefixed with the
count/ID so one can easily attribute events to specific instances.
As part of debugging subsequent patches, I ran into issues debugging the
interaction between multiple Experiments instances. To get to the bottom
of the problem, I had to make some changes to the logging framework.
This is the first patch in a sub-series dealing with logging.
This patch stops relying on the global logger. Subsequent patches will
make the logging output aid debugging.
Before this patch, experiment add-ons may have existed in the Addons
Manager without the Experiments service knowing about them. This detects
these unknown add-ons and uninstalls them. See the in-line comment on
the rationale behind this decision.
The added unit test fails without the Experiments.jsm change.
Experiment add-ons are now disabled by default on application load. It
is up to the Experiments Manager to enable them.
This means that experiments may not be able to reliably collect data or
modify behavior close to application startup. (There is a window between
when the Addon Manager initializes and when the Experiments Manager
initializes.) This window is acceptable for the initial version of the
experiments feature.
The Experiments Manager doesn't currently enable experiments on startup.
This will be addressed in a subsequent patch. Its tests do not regress
(indicating a lack of test coverage), so no harm no foul.
Experiment add-ons are now disabled by default on application load. It
is up to the Experiments Manager to enable them.
This means that experiments may not be able to reliably collect data or
modify behavior close to application startup. (There is a window between
when the Addon Manager initializes and when the Experiments Manager
initializes.) This window is acceptable for the initial version of the
experiments feature.
The Experiments Manager doesn't currently enable experiments on startup.
This will be addressed in a subsequent patch. Its tests do not regress
(indicating a lack of test coverage), so no harm no foul.
Experiment add-ons are installed and updated via the Experiments Manager
service. With this change, the Add-ons Manager lets experiment add-ons
play by their own rules without interference.
* no need to pass an addon/experiment ID to .disableExperiment()
* fix multiple-logging when multiple Experiments() objects are created as in tests
* ensures that all dirty writes actually get written
