1647923 - Add UrlbarProviderTabToSearch

Status: VERIFIED FIXED

(Firefox :: Address Bar, enhancement, P2)

Description

[Harry Twyford]

This work includes includes matching typed keywords to trigger this provider's active state. We might want to match only token aliases to avoid conflicts.

Comment 1

[Marco Bonardo [:mak]]

See also bug 1662172, if it helps we could split a provider that handles aliases. If it complicate things, we can leave it for later.

Comment 2

[Harry Twyford]

Attachment: Bug 1647923 - Add UrlbarProviderTabToSearch. r?adw!

This patch adds tab-to-search results, partially reusing the existing code in UrlbarProviderAutofill._matchSearchEngineDomain. Tests are included. Telemetry is included in a child revision.

This patch doesn't add the "Search <engine name> directly from the address bar." action text. Our current action text code l10n is in a .properties file and I thought adding branching translation logic in UrlbarView would be a mess. I think Marco might be converting that .properties file to Fluent in bug 1658629. If he is, I'll rebase my patch on his and add the new action text it in this patch. If he isn't, I'll file a follow-up for converting that .properties file and adding the tab-to-search action text, which we can address before preffing update2.tabToComplete on. Either way, I think this is ready for a first-round review.

This patch is based on D91076 and D91077. It doesn't have any functional dependency, but there are some conflicts, especially in the added telemetry.

Depends on D91077

Comment 3

[Harry Twyford]

Attachment: Bug 1647923 - Add tab-to-search telemetry. r?adw!

This adds tab-to-search telemetry, both for the new tabtosearch search mode entry point and for tabtosearch results in our usual Urlbar result-selection scalars. I also added a subtest in browser_urlbar_event_telemetry, but realized as I was writing it that it was not useful. We don't consider entering search more as the end of an engagement, so tab-to-search results will not appear in event telemetry. We already considered this in bug 1654680 and resolved it by adding detailed urlbar.searchmode.* scalars, so I don't consider it a blocker. I left the new subtest in since it was mostly done anyways and it can't hurt.

Depends on D91468

Comment 4

[Harry Twyford]

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

Comment 5

[Harry Twyford]

Comment on attachment 9177946 [details]
Bug 1647923 - Add tab-to-search telemetry. r?adw!

1. What questions will you answer with this data?

How users interact with new tab-to-search 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?

This is a new feature and does not have telemetry. It represents a significant search team investment and we'd like to monitor interactions with the new result. Furthermore, since it is a new result type, it would confound existing telemetry if we don't update it.

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. It would also confound existing Urlbar histograms like FX_URLBAR_SELECTED_RESULT_TYPE_2

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

Category 2: The keys for this scalar are strings describing what kind of search mode was entered when a tab-to-search result is selected. 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.

FX_URLBAR_SELECTED_RESULT_TYPE_2: "tabtosearch"

Category 2: We will record a new histogram value in FX_URLBAR_SELECTED_RESULT_TYPE_2: "tabtosearch". This is because tab-to-search is a new type of result. We want to know how often it is selected and with what relative frequency compared to other kinds of results.

Event telemetry: selType "tabtosearch"

Category 2: We will record whether the user last selected a tabtosearch result during a Urlbar event. In practice, this will not show up in Telemetry since opening a tab-to-search result enters search mode. Entering search mode does not currently mark the end of an engagement. This new selType may be more relevant in the future if we decide to measure search mode in event telemetry. This is all noted in the added documentation.

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 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 6

[Megan McCorquodale]

Comment on attachment 9177946 [details]
Bug 1647923 - Add tab-to-search 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 collection.

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

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 +

Comment 7

[Marco Bonardo [:mak]]

(In reply to Harry Twyford [:harry] from comment #2)

This patch doesn't add the "Search <engine name> directly from the address bar." action text. Our current action text code l10n is in a .properties file and I thought adding branching translation logic in UrlbarView would be a mess. I think Marco might be converting that .properties file to Fluent in bug 1658629.

yep, I am converting to Fluent. Should have the patch up today.

Comment 8

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/c6f68f0740eb
Add UrlbarProviderTabToSearch. r=adw,fluent-reviewers
https://hg.mozilla.org/integration/autoland/rev/286c876f4fa4
Add tab-to-search telemetry. r=adw

Comment 9

[Cristian Brindusan [:cbrindusan]]

https://hg.mozilla.org/mozilla-central/rev/c6f68f0740eb
https://hg.mozilla.org/mozilla-central/rev/286c876f4fa4

Comment 10

[Cristian Baica [:cbaica], Release Desktop QA]

Verified as fixed using the latest Fx83.0a1 on Windows 10 and macOS 10.13.
Telemtry is correctly registered when using the tab-to-search feature.