1665076 - Things going through UrlbarInput.search() are often considered typed.

Status: RESOLVED FIXED

(Firefox :: Address Bar, defect, P2)

Description

[Marco Bonardo [:mak]]

I'm not sure whether this is a problem for telemetry, but most things invoking gURLBar.search end up in search mode with entry: "typed", even if this can actually be invoked by the newtab handoff, a command, the touchbar or other.
See https://searchfox.org/mozilla-central/search?q=urlbar.search%28&path=&case=false&regexp=false

It may be worth checking which values we get for various operations involving search().

Comment 1

[Harry Twyford]

Here's a brief audit of our existing search mode entry points. The main takeaway is that handoff is broken, and that search() does indeed record typed. There doesn't seem to be any other problems. handoff's search goes through a function that was created for that purpose: searchWithAlias(). It doesn't appear to be recording any Telemetry. PBM's handoff goes through a different call point that was never updated.

A general problem with calls to search() with a restriction token is that the restriction token flickers in the Urlbar since it is quickly replaced by the search mode indicator. I think the solution to all these problems is to call setSearchMode directly from search() and add an optional searchModeEntry parameter to search() so callers can set the entry point. We can then get rid of searchWithAlias().

I also spoke to Teon and he asked that the search mode telemetry be as granular as possible. That means I'll introduce new search mode scalar suffixes for edge-case entry points, like the Touch Bar, the Library > Bookmarks > Search Bookmarks button and the Tab overflow > Search Tabs button.

Comment 2

[Marco Bonardo [:mak]]

Thanks for filling that up, I agree with your view the search() behavior should likely be forked for update2 and possibly pbm and normal tabs should go through a common code path.
For the other entries we can probably use something like "bookmarks_menu", "tabs_menu", "touchbar".

Comment 3

[Harry Twyford]

Attachment: Bug 1665076 - Call setSearchMode directly from search(), fix search mode handoff, and introduce new search mode probes. r?adw,mak

This patch calls setSearchMode directly from search(). This sets up a solution for the problem in the bug and also fixes the issue where a call to search() with a restriction token would flicker the token before it was replaced with the search mode indicator. I added new tabmenu and bookmarkmenu entry points to take advantage of this new functionality.

This also fixes the issues with handoff. Besides the problem of search() recording typed for handoff, handoff wasn't even registered as a Telemetry probe! That was my mistake. I added a test for handoff telemetry. It was only practical to test it in PBM since it uses a different implementation than about:home that's easier to test. I wrote a lengthy comment above the subtest about why I think this is okay.

Comment 4

[Harry Twyford]

Comment on attachment 9177252 [details]
Bug 1665076 - Call setSearchMode directly from search(), fix search mode handoff, and introduce new search mode probes. 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 three new search mode entry points: when the user is "handed off" from the new tab page search box to the Urlbar; selecting Library > Bookmarks > Search Bookmarks and selecting Tab overflow menu > Search Tabs. See bug 1657414 for a data-review request for a fourth new probe.

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 these entry points, 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, these entry points would currently record in a urlbar.searchmode.other probe, which does not allow us to distinguish them.

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.*

Category 2: Adding several urlbar.searchmode.* scalars. These scalars are suffixed with an entry point into search mode. This data-review is for urlbar.searchmode.handoff, urlbar.searchmode.tabmenu, and urlbar.searchmode.bookmarkmenu. The keys for these scalars 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 channels, 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 5

[Marco Bonardo [:mak]]

Comment on attachment 9177252 [details]
Bug 1665076 - Call setSearchMode directly from search(), fix search mode handoff, and introduce new search mode probes. r?adw,mak

Forwarding to Megan since Ben is leaving soon.

Comment 6

[Megan McCorquodale]

Comment on attachment 9177252 [details]
Bug 1665076 - Call setSearchMode directly from search(), fix search mode handoff, and introduce new search mode probes. 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 collection.

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 +

Comment 7

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/37c38c09d3dd
Call setSearchMode directly from search(), fix search mode handoff, and introduce new search mode probes. r=adw

Comment 8

[Andreea Pavel [:apavel]]

https://hg.mozilla.org/mozilla-central/rev/37c38c09d3dd