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
The Jira ticket (link in the bug) calls for two separate checkboxes for Firefox
Suggest results: a main checkbox plus a sponsored-suggestions checkbox. The
sponsored-suggestions checkbox is subordinate to the main checkbox, i.e., the
main checkbox has to be checked to turn on sponsored suggestions. This will
allow users to toggle sponsored suggestions separately from non-sponsored
suggestions. It's a change from the current situation where we have only one
pref and checkbox that control both sponsored and non-sponsored suggestions.
So part 1 of fixing this bug is to add a new pref for sponsored suggestions.
This revision keeps the current `suggest.quicksuggest` pref as the main pref and
adds a new `suggest.quicksuggest.sponsored` pref. I confirmed with Natalie that
we want to enable both prefs when the user opts in through the onboarding
dialog.
We currently record a telemetry event when `suggest.quicksuggest` is toggled. We
also want a similar event for the new pref, so this adds one.
The pref situation for Firefox Suggest is confusing but in summary:
* `browser.urlbar.quicksuggest.enabled`: The global toggle for the entire
Firefox Suggest rollout involving sponsored and non-sponsored suggestions, the
related telemetry and preferences UI, etc. This pref can be overridden by the
`quickSuggestEnabled` Nimbus variable. If false, neither sponsored nor
non-sponsored suggestions will be shown. If true, then we look at the
individual `suggest.quicksuggest` and `suggest.quicksuggest.sponsored` prefs.
* `browser.urlbar.suggest.quicksuggest`: Whether any Firefox Suggest results are
shown. This must be true to show both non-sponsored and sponsored results.
* `browser.urlbar.suggest.quicksuggest.sponsored`: Whether sponsored Firefox
Suggest results are shown. Both this pref and `suggest.quicksuggest` must be
true to show sponsored results.
Differential Revision: https://phabricator.services.mozilla.com/D124300
This uses `TelemetryStopwatch` to record the time between the `fetch` start and
its resolve. The new histogram is `FX_URLBAR_MERINO_LATENCY_MS`.
Depends on D124132
Differential Revision: https://phabricator.services.mozilla.com/D123993
This integrates a fetch to Merino in UrlbarProviderQuickSuggest. We continue to
do the remote settings fetch too. Per the Jira ticket, we should prefer the
Merino suggestion when both sources return one.
Each fetch is controlled by a new pref and Nimbus variable, so we can enable
them independently.
At first I started making a UrlbarProviderMerino class, but it's better to
modify UrlbarProviderQuickSuggest because everything besides the fetch source is
the same: We want to collect the same telemetry, have the same results and
payloads, etc.
Depends on D123852
Differential Revision: https://phabricator.services.mozilla.com/D123707
This introduces a new `result.isSuggestedIndexRelativeToGroup` property. When
true, `result.suggestedIndex` is relative to the result's group.
We can get rid of some hardcoded quick-suggest things with this.
I considered a `relativeSuggestedIndex` property that would replace
`suggestedIndex`, but it would have made `muxer._addSuggestedIndexResults` a
little more complex because it would need to know whether it should use
`relativeSuggestedIndex` or `suggestedIndex`. `UrlbarView._rowCanUpdateToResult`
would also need to be updated since it checks for suggestedIndex results. But
there are trade-offs either way and I'm open to using `relativeSuggestedIndex`.
While working on this I noticed that we broke the position of quick suggest
results in bug 1662167. They're supposed to be last in the outer general group,
and currently the muxer is hardcoded to put them last in `GENERAL`, but after
that bug `INPUT_HISTORY` actually comes last. To fix that I added a new
`GENERAL_PARENT` group that's used for the outer general group. Quick suggest
results now use this group, combined with a relative `suggestedIndex`, to come
last. I wanted to rename `GENERAL` to `PLACES` or `BOOKMARKS_HISTORY` and use
`GENERAL` for the outer group, but we use `GENERAL` in a ton of places (tests
especially) and I didn't want to touch blame for it all. I'm open to better
names than `GENERAL_PARENT`. I considered `FIREFOX_SUGGEST` but I don't think
it's a good idea to tie it to specific branding that may change.
Differential Revision: https://phabricator.services.mozilla.com/D122799
This patch also addresses bug 1645293. It essentially reverts parts 1 and 3 of bug 1616700 for users with searching disabled. Since we had to introduce branching behaviour, there are some new constructs like a shouldHandOffToSearchMode multi-pref in UrlbarPrefs.
Differential Revision: https://phabricator.services.mozilla.com/D118606
This patch also addresses bug 1645293. It essentially reverts parts 1 and 3 of bug 1616700 for users with searching disabled. Since we had to introduce branching behaviour, there are some new constructs like a shouldHandOffToSearchMode multi-pref in UrlbarPrefs.
Differential Revision: https://phabricator.services.mozilla.com/D118606
This fixes it locally for me. Apparently `:ref:` links to the first matching
global label, which in this case is an unrelated "Architecture overview" label
in a devtools doc. Instead we can use `:doc:` to link to another doc in the same
directory. We only need to specify the doc file's basename and Sphinx
automatically includes the doc's title in the final HTML.
See: https://www.sphinx-doc.org/en/master/usage/restructuredtext/roles.html#role-doc
Differential Revision: https://phabricator.services.mozilla.com/D116761
Given the result span problem described in bug 1699211 and bug 1699607,
currently there's no way for quick suggest to accurately specify the last index
as its suggested index.
Differential Revision: https://phabricator.services.mozilla.com/D109571
This adds event telemetry that's recorded when the
`browser.urlbar.suggest.quicksuggest` pref is toggled. This pref corresponds to
the checkbox in about:preferences#search labeled "Show suggested and sponsored
results in the address bar".
I used `contextservices.quicksuggest` as the event telemetry category name to be
similar to the `contextual.services.quicksuggest.*` scalars. Event names are
limited to 30 chars, so it couldn't be exactly the same.
This is based on my earlier revision for scalar telemetry in D106173.
Depends on D106173
Differential Revision: https://phabricator.services.mozilla.com/D106248
This adds three new keyed scalars:
* `contextual.services.quicksuggest.impression`: Incremented when a Quick
Suggest result is shown in an address bar engagement where the user picks any
result.
* `contextual.services.quicksuggest.click`: Incremented when the user picks a
Quick Suggest result (not including the help button).
* `contextual.services.quicksuggest.help``: Incremented when the user picks the
onboarding help button in a Quick Suggest result.
The changes to telemetry.rst and Scalars.yaml have more details.
I modified `TelemetryEvent.typeFromElement()` to return `"help"` for clicks on
the help button so that the quick suggest provider can tell whether the main
part of the result was picked or the help button. I left `"tiphelp"` for tip
help buttons in case anything depends on that.
Depends on D106060
Differential Revision: https://phabricator.services.mozilla.com/D106173
This adds event telemetry that's recorded when the
`browser.urlbar.suggest.quicksuggest` pref is toggled. This pref corresponds to
the checkbox in about:preferences#search labeled "Show suggested and sponsored
results in the address bar".
I used `contextservices.quicksuggest` as the event telemetry category name to be
similar to the `contextual.services.quicksuggest.*` scalars. Event names are
limited to 30 chars, so it couldn't be exactly the same.
This is based on my earlier revision for scalar telemetry in D106173.
Depends on D106173
Differential Revision: https://phabricator.services.mozilla.com/D106248
This adds three new keyed scalars:
* `contextual.services.quicksuggest.impression`: Incremented when a Quick
Suggest result is shown in an address bar engagement where the user picks any
result.
* `contextual.services.quicksuggest.click`: Incremented when the user picks a
Quick Suggest result (not including the help button).
* `contextual.services.quicksuggest.help``: Incremented when the user picks the
onboarding help button in a Quick Suggest result.
The changes to telemetry.rst and Scalars.yaml have more details.
I modified `TelemetryEvent.typeFromElement()` to return `"help"` for clicks on
the help button so that the quick suggest provider can tell whether the main
part of the result was picked or the help button. I left `"tiphelp"` for tip
help buttons in case anything depends on that.
Depends on D106060
Differential Revision: https://phabricator.services.mozilla.com/D106173
This adds event telemetry that's recorded when the
`browser.urlbar.suggest.quicksuggest` pref is toggled. This pref corresponds to
the checkbox in about:preferences#search labeled "Show suggested and sponsored
results in the address bar".
I used `contextservices.quicksuggest` as the event telemetry category name to be
similar to the `contextual.services.quicksuggest.*` scalars. Event names are
limited to 30 chars, so it couldn't be exactly the same.
This is based on my earlier revision for scalar telemetry in D106173.
Depends on D106173
Differential Revision: https://phabricator.services.mozilla.com/D106248
This adds three new keyed scalars:
* `contextual.services.quicksuggest.impression`: Incremented when a Quick
Suggest result is shown in an address bar engagement where the user picks any
result.
* `contextual.services.quicksuggest.click`: Incremented when the user picks a
Quick Suggest result (not including the help button).
* `contextual.services.quicksuggest.help``: Incremented when the user picks the
onboarding help button in a Quick Suggest result.
The changes to telemetry.rst and Scalars.yaml have more details.
I modified `TelemetryEvent.typeFromElement()` to return `"help"` for clicks on
the help button so that the quick suggest provider can tell whether the main
part of the result was picked or the help button. I left `"tiphelp"` for tip
help buttons in case anything depends on that.
Depends on D106060
Differential Revision: https://phabricator.services.mozilla.com/D106173
