This is a major change to the sequencing of Normandy's startup, since it now
applies startup preferences before the first async. This makes preference
changes happen synchronously during BrowserGlue's initialization phase. This
timing is something we have worked around frequently in the past.
This may affect some other features, but I believe they will all still work as
expected. Future features will be easier to integrate with Normandy, since the
timing of this phase is more predictable now.
Differential Revision: https://phabricator.services.mozilla.com/D115716
When a user changes a preference involved in a Normandy experiment, we no
longer immediately end the experiment. This caused a problem because Normandy
didn't check for user changes when resetting prefereces at the end of an
experiment. As a result it would reset all preferences back to their original
values on the specified branch, even if that would mean changing a preference
it knows the user had modified.
This change causes Normandy to never reset the user branch of an experiment
preference that the user has changed. This is true even if the user changes the
preference away from the experimental value and then back to it.
Differential Revision: https://phabricator.services.mozilla.com/D115713
This reverses a decision that was made in the original design of Normandy's preference experiments. That decision was made assuming simple experiments that only change one preference.
Today, preferences are more complicated, have more interactions, and often change more than one preferences. Unenrolling users from experiments due to preferences changing causes bugs, unexpected experiences for users, and bad experiment outcomes.
This change will make Normandy act more in alignment with how experimenter owners and data analysts already treat it, improving the overall experience of the experiments program.
Differential Revision: https://phabricator.services.mozilla.com/D112070
When there is a failure to load the experiments store, Normandy now simply
resets the store back to an empty set which is generally a safe operation.
Being resilient to errors here is especially important now that about:support
shows data from Normandy. Errors in loading data for about:support can cause
the entire page to be blank, blocking critical support information.
This is a safe operation from a clients point of view because withouot this
information Normandy will assume that no clients should be enrolled. It may
take a restart, but eventually it will reset the client back to default if
there are I/O errors.
Differential Revision: https://phabricator.services.mozilla.com/D109562
Without this change, profiles that participated in the rollout that turned on WebRender for qualified Intel devices will continue to due extraneous work every start up to set the relevant preference, even though nothing is reading it. The information that the profile is active in the rollout also shows up in telemetry and about:support data unnecessarily.
Differential Revision: https://phabricator.services.mozilla.com/D108831
Normandy retrieves recipes from Remote Settings, and any recipes that are not
included in the collection are assumed to be disabled on the server. This is a
generally effective strategy, but it has a bad failure case. In certain
infrastructure failures, Remote Settings will report an entirely empty
collection to Normandy.
This patch changes Normandy so that an empty recipe collection is classified as
a temporary error. Instead of processing recipes as normal, it will wait some
time (currently seven days), expecting the problem to be resolved. This
provides a good balance between being robust to infrastructure problems while
also still eventually returning the system to a normal state if Normandy is
shut down without accounting for this behavior.
Differential Revision: https://phabricator.services.mozilla.com/D107932
Normandy retrieves recipes from Remote Settings, and any recipes that are not
included in the collection are assumed to be disabled on the server. This is a
generally effective strategy, but it has a bad failure case. In certain
infrastructure failures, Remote Settings will report an entirely empty
collection to Normandy.
This patch changes Normandy so that an empty recipe collection is classified as
a temporary error. Instead of processing recipes as normal, it will wait some
time (currently seven days), expecting the problem to be resolved. This
provides a good balance between being robust to infrastructure problems while
also still eventually returning the system to a normal state if Normandy is
shut down without accounting for this behavior.
Differential Revision: https://phabricator.services.mozilla.com/D107932
CLOSED TREE
Backed out changeset 0e278d44bfac (bug 1696058)
Backed out changeset 3fe663d2b384 (bug 1693581)
Backed out changeset 38ba1cfafe7a (bug 1689502)
The 30 second delay and 3x max retries were chosen arbitrarily.
This avoids a potential race condition where the RecipeRunner is triggered before Normandy has fully initialized. When this happens, recipes can wrongly unenroll or graduate, causing many problems and confusing telemetry.
Differential Revision: https://phabricator.services.mozilla.com/D103704
Add a mechanism to indicate that specific Normandy rollouts no longer apply to
this version of Firefox. Normally this is handled by the preference specified
by the rollout changing their built-in values to match the rollout values.
However, this isn't always possible, such as if the preference is removed
instead of being switch to on by default, or if the preference cannot be
enabled by default for all users, but is conditionally enabled by another
feature.
Differential Revision: https://phabricator.services.mozilla.com/D102981
Allow-list all Python code in tree for use with the black linter, and re-format all code in-tree accordingly.
To produce this patch I did all of the following:
1. Make changes to tools/lint/black.yml to remove include: stanza and update list of source extensions.
2. Run ./mach lint --linter black --fix
3. Make some ad-hoc manual updates to python/mozbuild/mozbuild/test/configure/test_configure.py -- it has some hard-coded line numbers that the reformat breaks.
4. Make some ad-hoc manual updates to `testing/marionette/client/setup.py`, `testing/marionette/harness/setup.py`, and `testing/firefox-ui/harness/setup.py`, which have hard-coded regexes that break after the reformat.
5. Add a set of exclusions to black.yml. These will be deleted in a follow-up bug (1672023).
# ignore-this-changeset
Differential Revision: https://phabricator.services.mozilla.com/D94045
Allow-list all Python code in tree for use with the black linter, and re-format all code in-tree accordingly.
To produce this patch I did all of the following:
1. Make changes to tools/lint/black.yml to remove include: stanza and update list of source extensions.
2. Run ./mach lint --linter black --fix
3. Make some ad-hoc manual updates to python/mozbuild/mozbuild/test/configure/test_configure.py -- it has some hard-coded line numbers that the reformat breaks.
4. Make some ad-hoc manual updates to `testing/marionette/client/setup.py`, `testing/marionette/harness/setup.py`, and `testing/firefox-ui/harness/setup.py`, which have hard-coded regexes that break after the reformat.
5. Add a set of exclusions to black.yml. These will be deleted in a follow-up bug (1672023).
# ignore-this-changeset
Differential Revision: https://phabricator.services.mozilla.com/D94045
Allow-list all Python code in tree for use with the black linter, and re-format all code in-tree accordingly.
To produce this patch I did all of the following:
1. Make changes to tools/lint/black.yml to remove include: stanza and update list of source extensions.
2. Run ./mach lint --linter black --fix
3. Make some ad-hoc manual updates to python/mozbuild/mozbuild/test/configure/test_configure.py -- it has some hard-coded line numbers that the reformat breaks.
4. Add a set of exclusions to black.yml. These will be deleted in a follow-up bug (1672023).
# ignore-this-changeset
Differential Revision: https://phabricator.services.mozilla.com/D94045
