1398270 - Unknown source for one-off search: header error when clicking on search header

Status: VERIFIED FIXED

(Firefox :: Search, defect, P2)

Description

[Mike Kaply [:mkaply]]

After typing in a search, you can show the dropdown and then click on the header "Yahoo search" or "Google search" and a search will be executed.

You'll see this error in the console though:

Unknown source for one-off search: header  BrowserUsageTelemetry.jsm:405

This is actually a known source for one-off, so we should be reporting it correctly.

Comment 1

[Chris H-C :chutten]

Sounds like one just needs to add the source to KNOWN_ONEOFF_SOURCES in BrowserUsageTelemetry near http://searchfox.org/mozilla-central/source/browser/modules/BrowserUsageTelemetry.jsm#50

Alessio, is this so?

Comment 2

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

Well, it's not exactly a one-off, nor it's a normal search. It's wrong that we don't account for it, but it may also be wrong to count it as a one-off search.
I must also note this doesn't happen for the urlbar that is currently our primary target, though the urlbar shows the default engine, thus we could consider this header the same thing? It's also only reachable through mouse click, that makes it a little bit of an edge-case.

This is something to be evaluated directly by who manages/analyzes the collected data. Dave?

Comment 3

[Panos Astithas (he/him) [:past] (please ni?)]

I'm surprised the search bar header is clickable. I would have expected it to match the awesomebar header which isn't. Adding Philipp for UX guidance here.

Comment 4

[Dave Zeber [:dzeber]]

Sorry for the delay. I don't think this should be counted as a one-off. I understand one-offs to mean that the user consciously opted to use a non-default engine. This is just a different way of getting to a default-engine searchbar search.

That said, the only place where this makes a difference is in UITelemetry (and possibly the browser.engagement.navigation scalars), which is not commonly used at the moment. The oneoff sources are not recorded in standard Telemetry SEARCH_COUNTS. If we were counting these header searches, they would show up as `<engine>.searchbar` - the same as any other searchbar search using the default engine. (One-off searches are detected in standard Telemetry as those using a non-default engine).

I agree that it should be fixed. However, I expect this is an edge case, even more so with the searchbar going away for most people in 57.

Comment 5

[Florian Quèze [:florian]]

(In reply to Panos Astithas [:past] (please ni?) from comment #3)
> I'm surprised the search bar header is clickable. I would have expected it
> to match the awesomebar header which isn't. Adding Philipp for UX guidance
> here.

There may be some confusion on the word "header" here.

In the search bar we are talking about the first line that's at the top of the panel, above suggestions, and that shows what the default engine currently is. We made it clickable in bug 1110235 per Philipp's request.

I think in the awesomebar when you say "header" you are talking about the line above the one-off buttons that says "Search for <query> with:".

Comment 6

[Florian Quèze [:florian]]

This bug causes noise when running the browser/components/search/test/browser_oneOffHeader.js test.

Comment 7

[Mike Kaply [:mkaply]]

You also get the same error if you use paste and search:

Unknown source for one-off search: paste

The problem here seems to be there are things that aren't one off searches (paste, header) that we are counting as such here:

https://searchfox.org/mozilla-central/source/browser/components/search/content/search.xml#424

We need to do something different because a) we're producing an error and b) we're not recording this data in telemetry.

We just need to decide what the right thing is and just do it.

Comment 8

[Mark Banner (:standard8)]

Bug 1662553 is going to be dropping this error message.

Comment 9

[Mark Banner (:standard8)]

Fixed by bug 1662553.

Comment 10

[Florencia Di Ciocco, NI to vbalducci]

Hi,
I verified that I could reproduce this bug with 85.0a1 (2020-12-02) (64-bit) and then I verified that this is fixed on 86.0a1 (2021-01-05) (64-bit) on w10.

Regards, Flor.