Change tests and snippets in documentation to use `Date.now()` instead of an arbitrary number like `42`.
This way, we make sure the packaged dump isn't loaded on top of the tests data. Indeed, since Bug 1718083 we load the packaged dump if it's newer than local data.
Differential Revision: https://phabricator.services.mozilla.com/D145579
This adds a new `quickSuggestRemoteSettingsDataType` Nimbus variable whose value
will be used as the `type` filter when fetching data from remote settings.
Differential Revision: https://phabricator.services.mozilla.com/D145266
This revision does the following:
* Add a new Nimbus variable `quickSuggestBlockingEnabled` with a fallback pref
to show the block button on the usual non-best-match quick suggest rows.
* Previously we supported the block button only on best match rows. This keeps
that, and it also adds a Nimbus variable `bestMatchBlockingEnabled` for it.
We only had a pref for it.
* Change the name of the `browser.urlbar.quickSuggest.blockedDigests` pref to
`browser.urlbar.quicksuggest.blockedDigests` -- i.e., "quicksuggest" should be
in all lowercase, not camel case, since that's what all quick suggest prefs
use. We don't need to worry about a pref migration because blocking has never
been enabled.
* When setting the `browser.urlbar.quicksuggest.blockedDigests` pref, ignore the
resulting `onPrefChanged()` listener call. I do this by keeping a new
`_updatingBlockedDigests` property, similar to `_updatingImpressionStats`
added in D142152.
* Copy the browser_quicksuggest_bestMatch.js test to a new
browser_quicksuggest_block.js test that is specifically for testing blocking.
The new test checks both usual quick suggest rows and best matches.
Depends on D142780
Differential Revision: https://phabricator.services.mozilla.com/D143246
This implements Suggest impression frequency capping. Capping is performed
separately for sponsored and non-sponsored suggestions. Capping is not
per-suggestion; it's per type of suggestion, either sponsored or non-sponsored.
Capping can be enabled separately for each type. It's disabled by default for
both types with Nimbus variables for each.
Caps are specified in the quick suggest config in remote settings. There are two
kinds of caps: interval and lifetime. Multiple overlapping caps are supported,
for example a per-hour cap, a per-day cap, and a lifetime cap.
The user's impression stats are kept locally and stored in a pref. A "stats
object" corresponding to each cap interval is kept. Each stats object keeps
track of its corresponding cap's interval, the date at which the current
interval period started, and the impression count during the current interval
period. (For the lifetime cap, the interval in the stats object is Infinity.)
Each time a suggestion impression is recorded, the counters in all the
suggestion type's stats objects are incremented. Once a counter for any stats
object is reached, we stop showing that type of suggestion.
When the interval of a stats object has elapsed, its counter is reset. In this
revision, we check for elapsed intervals each time a suggestion is shown. In the
future when we add telemetry in bug 1761058, we will need to record telemetry
events for intervals where caps were not hit, so we may need to do this check
more often (for example near the beginning of `startQuery()`) or even do it on a
repeating timer.
There's some slightly complicated logic for handling changes in the cap config
since it's likely to change over time as we experiment with it (see
`_validateImpressionStats()`).
This revision also makes a few minor improvements unrelated to the bug.
Differential Revision: https://phabricator.services.mozilla.com/D142152
When enabled, this feature restricts the existing
`setDefaultPDFHandler` Nimbus feature to only set Firefox as the
default PDF handler when the existing handler is a known browser.
Depends on D142147
Differential Revision: https://phabricator.services.mozilla.com/D142148
Not all features are complicated enough to require full on JSON schema to
describe their variables. For these simpler features, we generate (a lax) JSON
schema based on the contents of their `variables` field to validate them. This
way we can re-use the existing validation mechanism and do not have to write a
bespoke validator.
The schema generated is intended to be compatible with the one generated by
Experimenter.
Differential Revision: https://phabricator.services.mozilla.com/D141892
A test that tested featureless experiments has been removed, as the experiment
schema dictates that one of `feature` or `features` is required.
Tests have been updated to match the in-tree schema, as they previously did not
validate.
Differential Revision: https://phabricator.services.mozilla.com/D138928
The result of ExperimentFakes.recipe() has been updated to match the updated schema.
Some unit tests have been updated to pass with the updated schema.
Differential Revision: https://phabricator.services.mozilla.com/D140760
This Nimbus experiment code was added in bug 1719070 to test if sending a "Firefox 100" UA string causes any major webcompat problems.
The moz.build change was added in bug 1724635 to fix a Thunderbird build break. MOZ_BUILD_APP_IS_BROWSER = true when building Firefox, false when building Thunderbird.
Differential Revision: https://phabricator.services.mozilla.com/D126408
This modifies the Nimbus update observer in UrlbarPrefs so that it does not
update the Firefox Suggest scenario unnecessarily. The scenario and the prefs
related to the scenario only need to be updated when either of these happens:
* A relevant Nimbus variable changes
* The current default-branch value of a relevant pref is incorrect for the
intended scenario
Currently, any time a pref changes that is declared as a fallback pref for a
Nimbus urlbar variable, we end up updating the scenario all over again even if
it was some totally unrelated variable like `bestMatchEnabled`.
We have very good test coverage for scenario updates, so I'm confident that this
revision works properly and that we can catch regressions when we modify related
code in the future.
While working on this, I found that the `quickSuggestNonSponsoredEnabled` was
accidentally removed by D130159 (https://hg.mozilla.org/mozilla-central/rev/ccda4432cdc4d7180a9304e05b52f046616bbf2b)
so I added it back. We haven't used this variable in any experiments or rollouts
so it was never a problem.
Differential Revision: https://phabricator.services.mozilla.com/D140425
This modifies the Nimbus exposure event logic for users in the
`firefox-suggest-best-match` experiment so that the event is recorded the first
time a best match is shown (or would have been shown). For all other users,
there's no change: The event is recorded the first time a Suggest suggestion is
shown.
Depends on D139452, D139576
Differential Revision: https://phabricator.services.mozilla.com/D139995
This patch ended up adding some complexity to about:welcome, as the
language switching needs to eagerly perform fallible asynchronous
actions. Specifically it needs to get the list of addons and
pre-emptively install the langpack, which can take time, and can fail.
This necessitated building a custom React components and custom hooks to
be able to deal with these requirements.
The following command will allow for the testing of this feature.
./mach run \
--temp-profile \
--setpref "extensions.getAddons.langpacks.url=https://mock-amo-language-tools.glitch.me/?app=firefox&type=language&appversion=%VERSION%" \
--setpref "intl.multilingual.aboutWelcome.languageMismatchEnabled=true" \
--setpref "intl.multilingual.aboutWelcome.systemLocaleOverride=es-ES" `#(optional)` \
-- --new-tab about:welcome
Differential Revision: https://phabricator.services.mozilla.com/D138831
This patch ended up adding some complexity to about:welcome, as the
language switching needs to eagerly perform fallible asynchronous
actions. Specifically it needs to get the list of addons and
pre-emptively install the langpack, which can take time, and can fail.
This necessitated building a custom React components and custom hooks to
be able to deal with these requirements.
The following command will allow for the testing of this feature.
./mach run \
--temp-profile \
--setpref "extensions.getAddons.langpacks.url=https://mock-amo-language-tools.glitch.me/?app=firefox&type=language&appversion=%VERSION%" \
--setpref "intl.multilingual.aboutWelcome.languageMismatchEnabled=true" \
--setpref "intl.multilingual.aboutWelcome.systemLocaleOverride=es-ES" `#(optional)` \
-- --new-tab about:welcome
Differential Revision: https://phabricator.services.mozilla.com/D138831
This revision involves two prefs:
`browser.urlbar.bestMatch.enabled`
Currently this pref corresponds to the user's choice of whether to enable best
matches. This revision changes its meaning so that it's now the gate for the
whole best match feature. If it's false, then the best match preferences UI will
not appear and best matches will not appear in the urlbar. If it's true, then
the preferences UI will appear, and the second pref below controls whether best
matches will appear in the urlbar.
`browser.urlbar.suggest.bestmatch`
This new pref takes on the old meaning of the first pref: It corresponds to
whether the user has enabled best matches.
With these two prefs, we have a similar setup to the quick suggest prefs: one
pref for the whole feature, `quickSuggest.enabled`, and another pref for whether
quick suggest results will appear in the urlbar -- actually two prefs since
there are two kinds of quick suggest results, `suggest.quicksuggest.sponsored`
and `suggest.quicksuggest.nonsponsored`.
Also, Product says best match should be enabled by default (see
"design/interaction notes" at the bottom of [this Figma](https://www.figma.com/file/seJ2ZA4v3FgoV7jCxUR74B/Firefox-Suggest?node-id=6011%3A7701)),
so I set the default value of `browser.urlbar.suggest.bestmatch` to true, which
means it will be enabled by default when the feature gate is enabled.
Part 2 of this bug will update the preferences UI.
Differential Revision: https://phabricator.services.mozilla.com/D138583
