Instead of the regular tab-to-search result, the first N times we should show an intervention style result. After you encounter this intervention result N times, you will see the regular tab-to-search result from then on.

There are a few unknowns that need to be clarified:

• How many times should we show tab-to-search as a tip and not as a normal result?
• Should we show the tip version at most once per session, like Search Tips?
• Product suggested adding an "Okay, Got It" button to dismiss the tip-sized tab-to-search results. If we do this, then we will need some other kind of target on the tip to enter search mode. Or we make the entire rest of the tip a target?

For the onboarding intervention, we'll use a two-row intervention. It will have the same animation as the regular result (see Bug 1647924). The icon (coming soon) should be 32x32.

The selected state will use a double high highlight to cover the entire result.

More details from UX:

• We will show the large-size result a maximum of 10 times total and at most twice per session. These maximums should be configurable to allow for experimentation.
• Once the large result is selected, we should never show it again.

This is nearly ready for review. Barring review feedback, I don't plan to make significant changes to the patch, so it's safe to start reading it over if you feel like it. I plan on splitting it up into more digestible parts before actually tagging anyone for review. There are a couple of issues that still need to be resolved:

• This patch does not use the icon in the UX spec. I'm waiting on that icon and just using the engine icon in the meantime.
• We also don't have a spec for how the result should wrap at narrow window widths, so I put some placeholder behaviour in.
• It appears dynamic results are incapable of overriding the CSS for normal Urlbar classes unless !important is used, regardless of specificity. Thus a few rules in dynamic-tabToSearch.css use !important, which isn't ideal. It appears this is because dynamic result stylesheets are loaded as AGENT_SHEETs. Changing that value to AUTHOR_SHEET allows the dynamic result CSS to override the normal Urlbar classes without !important. This strikes me as a tough issue. dynamic-tabToSearch.css is an agent sheet since it's provided by the browser. I do wonder if its defensible to load it as an author sheet since it will usually be loaded by an extension/external developer (this might be a stretch :). I'm not well-versed enough in the technicalities here to really make a call, so I'm eager to hear if @dao or @adw have any thoughts on how to resolve this issue.

Try run for my WIP patch, just to check what needs to be fixed: https://treeherder.mozilla.org/#/jobs?repo=try&revision=b75ccc78271ca3a9d9600171a059421c16945832

Depends on D93015

https://treeherder.mozilla.org/#/jobs?repo=try&revision=5bc3e3ce2003ef154d71294bf108d850a39b5596

Comment on attachment 9180744 [details]
Bug 1665934 - Part 3 - Add tab-to-search onboarding telemetry. r?adw!

1. What questions will you answer with this data?

How the new tab-to-search feature in the Urlbar is use. I'm adding telemetry for tab-to-search onboarding results. These are large tab-to-search results that appear the first few times the user sees one of those results.

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:

We want to know if users see and interact with the onboarding results to know if they successfully get people to use tab-to-search results.

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 search mode 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.tabtosearch_onboard

Category 2: The keys for this scalar are strings describing what kind of search mode was entered after the user selects a tab-to-search onboarding result. This will be the name of a search engine, like "Google", or "DuckDuckGo". 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 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.

Depends on D93112

https://treeherder.mozilla.org/#/jobs?repo=try&revision=f9bfb72a344ad063b7b26e6ef02d24b868443c03

Ah sorry, forgot about the data-review. I'm going to request backout.

Backed out as requested.

Backout link: https://hg.mozilla.org/integration/autoland/rev/aa02755673cf3e01631b9164e69dcc61b219dd2c

Please leave this open until Part 3 of the patch lands, covering telemetry.

Comment on attachment 9180744 [details]
Bug 1665934 - Part 3 - Add tab-to-search onboarding telemetry. r?adw!

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?
   Teon Brooks and the search team 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/c297c729eaa2
https://hg.mozilla.org/mozilla-central/rev/b256f36594db
https://hg.mozilla.org/mozilla-central/rev/0cd1d314471b
https://hg.mozilla.org/mozilla-central/rev/e9bece1d1360

All the parts landed afaict.