Please see the bug for info. This revision changes the URL of the adaptive
history doc to the new published doc. Ultimately this doc should live in-tree
but until then this is a nice, simple improvement.
Differential Revision: https://phabricator.services.mozilla.com/D150516
The documentation says this change was made in 103 because I'll request uplift
to Beta 103.
This also adds documentation for the new `sid` and `seq` Merino params from
D150289. I should have update the doc there, and since I'm modifying it now
anyway let's do it here.
Differential Revision: https://phabricator.services.mozilla.com/D150490
This records multiple reset "events" inside a single telemetry event instead of
using one telemetry event per reset event like we currently do. It also stops
recording reset events for interval periods that elapsed while the app wasn't
running. This will prevent us from recording a bunch of events at once like we
currently do. Please see the bug for more background.
A new `eventCount` property in the telemetry event's `extra` indicates the
number of reset events that are being reported in the telemetry event.
I talked with Rebecca about these changes and she's OK with them.
Differential Revision: https://phabricator.services.mozilla.com/D145049
* Add a new block ping. I called it "block" to be consistent with internal
naming in urlbar/quick suggest, but let me know if you'd prefer "dismiss"
* Add a `iab_category` property to suggestion objects returned from
UrlbarQuickSuggest (i.e., remote settings. Merino will separately need to
include this in its suggestions too)
* Add a new `sponsoredIabCategory` payload property to quick suggest results so
we can record `iab_category` in the ping
* Modify existing tests to include `iab_category` in mock sponsored suggestions
and `sponsoredIabCategory` in the expected payloads
* Replace the several QuickSuggestTestUtils functions for checking pings with a
single function that makes sure only the specified pings are recorded and
nothing more
Depends on D143331
Differential Revision: https://phabricator.services.mozilla.com/D143674
This adds a new "engagement" telemetry event for quick suggest results. The
event's object can be the following values:
* "block": The user dismissed ("blocked") the suggestion.
* "click": The user picked the suggestion.
* "help": The user picked the suggestion's help button.
* "impression_only": The user picked some other row.
For this particular bug, we're interested in recording blocks, but there's no
reason not to generalize that idea into an engagement event like this that
records all types of interactions.
Depends on D143254
Differential Revision: https://phabricator.services.mozilla.com/D143331
This does several things:
* Add new scalars for blocked suggestions
* Record the impression custom telemetry ping when a suggestion is blocked
* Remove the code that gets the index of the quick suggest result when the
engagement telemetry is recorded. We can replace all that with simply
`result.rowIndex`, but we need to store the result we last added in a property
to do that, so I replaced `_addedResultInLastQuery` with
`_resultFromLastQuery`
* Modify the urlbar engagement telemetry event code by adding the following
`selType` values: "quicksuggest", "block". We can use the `selType` in the
quick suggest engagement telemetry code to determine whether the block button
or the main part of the row was clicked.
Depends on D143246
Differential Revision: https://phabricator.services.mozilla.com/D143254
This adds a new "impression_cap" telemetry event with several things recorded in
the `extra` object. Please see the updated documentation and Events.yaml for
details.
This is another big patch but like D142152 most of it is the test.
Depends on D142152
Differential Revision: https://phabricator.services.mozilla.com/D142780
This adds two new scalars for engagements and abandonments in the urlbar:
```
urlbar.engagement
urlbar.abandonment
```
We already have engagement event telemetry but it's preffed off by default, and
for the upcoming best match experiment, data science would prefer scalars so we
can easily measure total engagement volume. (See bug 1752953 comment 22.)
Recording simple scalars for engagements and abandonments in addition to the
optional event telemetry seems totally reasonable.
The existing `urlbar.picked.*` scalars are sort of proxies for engagement, but a
single scalar would make analysis easier, and there is no similar existing
scalar for abandonments.
This revision hooks into the `TelemetryEvent` class, but it records the scalars
regardless of `browser.urlbar.eventTelemetry.enabled` because there's no reason
to not always enable it.
Differential Revision: https://phabricator.services.mozilla.com/D140287
This adds new keyed scalars for best match that are analogous to the current
non-best-match scalars, but they are broken out by sponsored vs. non-sponsored:
```
contextual.services.quicksuggest.impression_sponsored_bestmatch
contextual.services.quicksuggest.impression_nonsponsored_bestmatch
contextual.services.quicksuggest.click_sponsored_bestmatch
contextual.services.quicksuggest.click_nonsponsored_bestmatch
contextual.services.quicksuggest.help_sponsored_bestmatch
contextual.services.quicksuggest.help_nonsponsored_bestmatch
```
For best matches, these new scalars are incremented *in addition to* the current
non-best-match scalars.
Differential Revision: https://phabricator.services.mozilla.com/D140286
This does the following:
* Add the urlbar root directory to the list of sphinx-js directories
* Add three new rst files for the automatically generated API docs for
UrlbarController, UrlbarInput, and UrlbarView
* Add a new top-level section to the urlbar's index.rst for these three docs
* Tweak two JSDocs in UrlbarSearchOneOffs so that sphinx-js doesn't complain
This should be a good starting place for integrating automatically generated API
docs into the urlbar docs, and we can iterate on it from here.
Differential Revision: https://phabricator.services.mozilla.com/D139780
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
* Add `match_type` to the impression and click pings
* Clean up the ping code a little while I'm here
* Add a test task
* Improve the test code that checks the pings: Make sure pings don't have extra
unexpected properties and make the code a little nicer. Update existing tasks
as necessary
* Update the telemetry doc
Differential Revision: https://phabricator.services.mozilla.com/D139452
This enables suggestions by default in the online scenario. Data collection is
still disabled by default. With this revision, there's now no difference between
online and offline in terms of defaults.
Part 2 of this bug will modify the opt-in modal so that opting in or out affects
only the data-collection pref and not suggestions like it currently does.
For users who were already enrolled in online, saw the modal, and did not opt in
or otherwise enable suggestions, suggestions will remain disabled when they
upgrade. Users in online who did enable suggestions will continue to see them
when they upgrade. Users in online who did *not* see the modal will also have
suggestions enabled when they upgrade. That's unfortunate since they currently
have suggestions disabled, but based on telemetry data, the number of these
users is small, and it's a little risky to handle that case specifically because
if we're not careful we could end up disabling suggestions for all users coming
from 94.0.1 and earlier who enroll in online in the future. The code comment in
`UrlbarPrefs._migrateFirefoxSuggestPrefsUnversionedTo2Online()` and discussion
in D131751 talk about this.
For all other users, suggestions will default to enabled when/if they are
enrolled in online.
I added another prefs migration to implement all this.
I wrote a [test plan doc](https://docs.google.com/document/d/1tcbrBZmIaL_cQhvycoVL602kQqFtQvOBRhKV9zKqghE/edit?usp=sharing) to make sure all relevant upgrade paths work correctly
and I've verified it myself. I also added new automated tests of course.
Differential Revision: https://phabricator.services.mozilla.com/D131751
Merino providers are different content sources. Being able to change them with
a preference will aid in QA, allowing us to more easily test non-yet-launched
functionality.
Client variants are a part of the experimentation system, and may be used to
modify server behavior based on active client experiments.
Differential Revision: https://phabricator.services.mozilla.com/D133275
Otherwise, the warning is displayed:
```
WARNING: Could not lex literal_block as "json". Highlighting skipped.
```
Depends on D131092
Differential Revision: https://phabricator.services.mozilla.com/D131093
Now that we're likely not targeting a 94 dot release anymore, I'd like to go
ahead and rename the `suggest.quicksuggest` pref to
`suggest.quicksuggest.nonsponsored` as we considered doing before. There won't
be a better time to do it.
Depends on D128665
Differential Revision: https://phabricator.services.mozilla.com/D130565
This adds telemetry for the new data-collection pref:
* Adds a `data_collect_toggled` object to the `contextservices.quicksuggest`
telemetry event
* Adds the new pref to telemetry environment
Depends on D128661
Differential Revision: https://phabricator.services.mozilla.com/D128665
This is a big revision that makes a lot of changes. The core change is adding a
new pref to control data collection for Firefox Suggest and making the existing
non-sponsored and sponsored prefs independent of each other. The data-collection
pref defaults to false in every scenario; in online, the user is opted in to it
when they opt in to the modal, and in both online and offline the user will be
able to enable it in the preferences UI (part 2 of this bug, see below).
A new requirement for this bug that came up after I wrote my original patch in
D128579 is that we want the ability to enable Merino via an experiment, which
requires the data-collection pref to be true. That's tricky because data
collection will be exposed in the preferences UI. If the user disables it, we
don't want to override that. There's a distinction to draw between its being
disabled/enabled by default and its being disabled/enabled by the user. It's OK
to override the default but not the user's choice, and that's true not only for
this new data-collection pref but for all prefs exposed in the UI.
We can handle that by taking care to set prefs on the default and user branches
as appropriate. If a pref exposed in the UI has a value on the user branch, then
we can assume the user modified it, and ideally that value should stick around
indefinitely. On the other hand we can set default values as configured by
Nimbus on the default branch. If the user modified a pref, then it'll take
precedence since it's on the user branch.
To make user-modified preferences stick around indefinitely, I made them sticky
in firefox.js. That way even when user values are the same as default values,
the user-branch values will be preserved, which is not true of non-sticky prefs.
I added a new Nimbus variable for data collection, so we can use that to enable
it by default. It was trivial to add similar variables for the other UI-exposed
prefs, the two suggestions types, so I did that too.
This is all tested pretty thoroughly in browser_quicksuggest_configuration.js.
This is only part 1 of 4. Part 2 updates the prefs UI, part 3 adds telemetry for
the new data-collection pref (event telemetry when it's toggled, similar to the
existing prefs, and telemetry environment), and part 4 changes the name of
`browser.urlbar.suggest.quicksuggest` to
`browser.urlbar.suggest.quicksuggest.nonsponsored`.
For review, I'd suggest looking at parts in the following order:
1. UrlbarPrefs.jsm, browser_quicksuggest_configuration.js, and
test_quicksuggest_migrate.js.
The core changes are in UrlbarPrefs.jsm. The two test files document the
expected behavior of different scenarios/enrollments and prefs migrations.
browser_quicksuggest_configuration.js tests different enrollments and the
prefs stuff I mentioned above.
test_quicksuggest_migrate.js tests prefs migrations. I added a migration step
that's run on startup when the scenario is updated. There are two things we
need to do: decouple the existing `suggest.quicksuggest` prefs and initialize
the new data-collection pref. (For brevity I'll omit the `browser.urlbar`
prefix to all these pref names in this commit message.)
The `suggest.quicksuggest` pref now controls non-sponsored suggestions, and
the `suggest.quicksuggest.sponsored` now controls sponsored suggestions
independent of the other pref. The new data pref is
`quicksuggest.dataCollection.enabled`.
For the current online rollout on 92.0.1, we don't record the user's choice
to the opt-in modal, so the initial value of the data pref for existing users
is debatable. I Slacked with Natalie about it, and we think it's OK to
initialize it to allow data collection as long as the main
`suggest.quicksuggest` pref is true. The user may not have opted in to the
modal in that case, but if not, they enabled suggestions in
about:preferences, where we show a description under the main Firefox Suggest
checkbox about data sharing.
For new profiles (i.e., profiles that are created in versions of Firefox
where this revision has landed), the migration step runs but is effectively a
no-op.
2. UrlbarProviderQuickSuggest.jsm and UrlbarProviderQuickSuggest.jsm. The
changes here are again related to decoupling the `suggest.quicksuggest` prefs
and checking the data pref before recording data in telemetry and fetching
from Merino.
3. All the other tests. I ended up adding some checks to a lot of them and
simplifying some, especially browser_urlbar_telemetry_quicksuggest.js.
Depends on D130531
Differential Revision: https://phabricator.services.mozilla.com/D129224
This adds a new categorical histogram called `FX_URLBAR_MERINO_RESPONSE`. There
are four categories per the discussion in the bug:
0: success
1: timeout
2: network_error
3: http_error
Only one value is recorded per fetch, so for example if Merino times out but
then later finishes successfully, we only record the timeout.
Depends on D129772
Differential Revision: https://phabricator.services.mozilla.com/D130530
This does a couple of things:
* Instead of using the `not_now` telemetry event object for the cases where the
dialog is closed by the Escape key or some other atypical way, reserve
`not_now` -- renamed `not_now_link` -- specifically for clicks on the "Not
now" link and add two new objects: `dismissed_escape_key` and
`dismissed_other`. That should give us a little better understanding of how
the dialog is being dismissed. The new `not_now_link` name is to avoid
conflation with the previous meaning of `not_now`.
* Add a new `browser.urlbar.quicksuggest.onboardingDialogChoice` pref that
stores exactly the same values as the telemetry event. e.g., if the dialog is
accepted, then we'll record a telemetry event whose object is `accept` and
we'll also store `accept` in the pref.
I figure if we decide to show the onboarding again for people who have already
seen it, (1) we'll use this pref to decide the flow for any given user, and (2)
we'll need to add another pref for the user's response to the "v2" dialog, or
maybe we could morph this one into an array of responses or something more
complex like that.
Differential Revision: https://phabricator.services.mozilla.com/D127354
