When the Urlbar is focused, the Touch Bar shows several search shortcuts. When the urlbar.update2 prefs are enabled, these should enter search mode instead of their current behaviour of starting a search with a restriction token.

This work includes supporting Tags and Titles as Urlbar search modes.

If we make search automatically enter search mode when a restriction token (or any other token that should enter search mode) is present, then this will just work. I suggested that in D87908 too.

Yes, although this would still require supporting Tags and Title search modes. Or removing those as options in the Touch Bar.

Couldn't search just check whether the search string starts with a recognized search mode token? If it doesn't, then it would just do what it currently does. Actually it's probably more like: search sets the input value and starts a search, the search returns a heuristic, and then _on_input calls _searchModeForResult on the selected (heuristic) result and enters search mode if appropriate. I'm working on bug 1658964 and that's what I've got so far, for supporting restriction tokens.

Bumping this to P2 since bug 1658964 broke the Touch Bar buttons – there's now flickering when they are pressed and pressing the title/tags buttons doesn't clear existing search modes.

Depends on D91076

Comment on attachment 9177253 [details]
Bug 1657414 - Support search mode in the Touch Bar. r?adw,mak

This request is very similar to the one approved in bug 1654680 comment 12.

1. What questions will you answer with this data?

How the new search mode feature in the Urlbar is used, including how users find the feature and what parts of it they use the most. I'm adding telemetry for one new search mode entry point: the search shortcut buttons in the macOS Touch Bar.

2. Why does Mozilla need to answer these questions? Are there benefits for users? Do we need this information to address product or business requirements? Some example responses:

Without recording Telemetry on this entry point, our search mode data will be incomplete. We want to know how search mode is accessed to know what entry points to invest in or remove.

3. What alternative methods did you consider to answer these questions? Why were they not sufficient?

We plan on also doing user studies with this feature, but we want aggregate data to understand how it is used more broadly.

4. Can current instrumentation answer these questions?

No, this entry point would currently record in a urlbar.searchmode.other probe, which does not allow us to distinguish it from other entry points.

5. List all proposed measurements and indicate the category of data collection for each measurement, using the Firefox data collection categories found on the Mozilla wiki.

Measurements

urlbar.searchmode.touchbar

Category 2: The keys for this scalar are strings describing what kind of search mode was entered. In most cases, this will be the name of a search engine, like "Google", or "DuckDuckGo". It may also be one of "history", "bookmarks", or "tabs". We only collect the names of engines that are bundled with Firefox. If the user enters search mode with an engine they installed themselves, we record "other" as the key.

6. Please provide a link to the documentation for this data collection which describes the ultimate data set in a public, complete, and accurate way.

The documentation on Urlbar telemetry will be updated with this patch to describe the new probes.

7. How long will this data be collected? Choose one of the following:

The search team will permanently monitor this data. Teon will look after it.

8. What populations will you measure?

All macOS Desktop users, countries, and locales.

9. If this data collection is default on, what is the opt-out mechanism for users?

Standard telemetry opt-out.

10. Please provide a general description of how you will analyze this data.

We will use the measurement dashboard and STMO.

11. Where do you intend to share the results of your analysis?

Internally, with the search team and Firefox Desktop leadership.

12. Is there a third-party tool (i.e. not Telemetry) that you are proposing to use for this data collection?

No.

Comment on attachment 9177253 [details]
Bug 1657414 - Support search mode in the Touch Bar. r?adw,mak

forwarding to Megan.

Comment on attachment 9177253 [details]
Bug 1657414 - Support search mode in the Touch Bar. r?adw,mak

1. Is there or will there be documentation that describes the schema for the ultimate data set in a public, complete, and accurate way?
   Yes, this will be documented in the urlbar telemetry docs.

2. Is there a control mechanism that allows the user to turn the data collection on and off?
   Yes, users can opt out of telemetry.

3. If the request is for permanent data collection, is there someone who will monitor the data over time?
   Yes, Teon Brooks will monitor.

4. Using the category system of data types on the Mozilla wiki, what collection type of data do the requested measurements fall under?
   Category 2, interaction data.

5. Is the data collection request for default-on or default-off?
   Default on.

6. Does the instrumentation include the addition of any new identifiers?
   No new identifiers.

7. Is the data collection covered by the existing Firefox privacy notice?
   Yes.

8. Does there need to be a check-in in the future to determine whether to renew the data?
   No.

9. Does the data collection use a third-party collection tool?
   No.

data-review +

https://hg.mozilla.org/mozilla-central/rev/8c767027d7cf