The `urlbar.picked.searchmode.*` probes are incremented when a result is picked and the Urlbar is in search mode. That check is made [here](https://searchfox.org/mozilla-central/rev/d6d8ea296d3560615f04ec3cc5538b827aa3151f/browser/components/urlbar/UrlbarController.jsm#553). Unfortunately, when a result that _enters_ search mode is picked, the Urlbar is already in search mode preview when we arrive at that line. A bogus entry is recorded. This affects: `urlbar.picked.searchmode.tabtosearch` `urlbar.picked.searchmode.tabtosearch_onboard` `urlbar.picked.searchmode.keywordoffer` `urlbar.picked.searchmode.topsites_urlbar` I manually tested the other probes and they are unaffected. This includes `urlbar.picked.searchmode.shortcut`, which I understand is the one Product is most interested in. To fix this problem, we need to add a check that search mode is confirmed when those probes are incremented. I already have a patch ready. Since users _must_ pick a result to trigger the `keywordoffer` and `topsites_urlbar` search mode entry points, they always record a bogus entry in their `urlbar.picked.searchmode.*` probe. Thus, we can find their true values by subtracting the summed value of their `urlbar.searchmode.*` equivalent (e.g. `sum(urlbar.picked.searchmode.keywordoffer) - sum(urlbar.searchmode.keywordoffer)`). The true values of the tab-to-search probes are harder to discern. When the user tabs to the tab-to-search result and starts typing, we do not consider the tab-to-search result "picked" and so we don't record the bogus data. However if the user clicks the tab-to-search result or highlights it and presses Enter, the bogus data is recorded.
Bug 1675976 Comment 0 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
The `urlbar.picked.searchmode.*` probes are incremented when a result is picked and the Urlbar is in search mode. That check is made [here](https://searchfox.org/mozilla-central/rev/d6d8ea296d3560615f04ec3cc5538b827aa3151f/browser/components/urlbar/UrlbarController.jsm#553). Unfortunately, when a result that _enters_ search mode is picked, the Urlbar is already in search mode preview when we arrive at that line. A bogus entry is recorded. This affects: `urlbar.picked.searchmode.tabtosearch` `urlbar.picked.searchmode.tabtosearch_onboard` `urlbar.picked.searchmode.keywordoffer` `urlbar.picked.searchmode.topsites_urlbar` I manually tested the other probes and they are unaffected. This includes `urlbar.picked.searchmode.shortcut`, which I understand is the one Product is most interested in. To fix this problem, we need to add a check that search mode is confirmed when those probes are incremented. I already have a patch ready. ~~Since users _must_ pick a result to trigger the `keywordoffer` and `topsites_urlbar` search mode entry points, they always record a bogus entry in their `urlbar.picked.searchmode.*` probe. Thus, we can find their true values by subtracting the summed value of their `urlbar.searchmode.*` equivalent (e.g. `sum(urlbar.picked.searchmode.keywordoffer) - sum(urlbar.searchmode.keywordoffer)`).~~ ~~The true values of the tab-to-search probes are harder to discern. When the user tabs to the tab-to-search result and starts typing, we do not consider the tab-to-search result "picked" and so we don't record the bogus data. However if the user clicks the tab-to-search result or highlights it and presses Enter, the bogus data is recorded.~~ EDIT: The crossed out information above is inaccurate. See comment 5.