1134634 - Default search engine not properly set for region

Status: RESOLVED INCOMPLETE

(Firefox for Android Graveyard :: General, defect)

Description

[Aaron Train [:aaronmt]]

Based on internal survey results in some cases the default search engine is not properly set for the region. In most cases it looks like the attempt happens over cellular connection.

Comment 1

[Mark Finkle (:mfinkle) (use needinfo?)]

Is this bug tracking the situation where:
1. Typing+Enter in awesomescreen uses Yahoo
2. Yahoo is shown first in the awesomescreen list of search engines
3. Settings > Customize > Search shows Google as default

Or is this different?

Comment 2

[Mark Finkle (:mfinkle) (use needinfo?)]

In :mconley's case the browser.search.countryCode and the browser.search.region were set to the correct value, but the awesomescreen was using the wrong engine, right? Was the Settings > Customize > Search default set to the wrong value too?

Comment 3

[Aaron Train [:aaronmt]]

(In reply to Mark Finkle (:mfinkle) from comment #1)
> Is this bug tracking the situation where:
> 1. Typing+Enter in awesomescreen uses Yahoo
> 2. Yahoo is shown first in the awesomescreen list of search engines
> 3. Settings > Customize > Search shows Google as default

Let's use bug 1073775 for that where there was some discussion. Seems to happen for upgraded users where things have got botched at some point.

> Or is this different?

Let's go with mconley's & marcia (cc'ed) case where the default set is simply wrong. Couple others in the internal survey tracking too.

Comment 4

[Mike Conley (:mconley) (:⚙️)]

Playing with this a bit, I suspect we have a little timing issue.

First, I switch to my cell data.

I clear my user data, and then re-open Firefox Beta. I click "Start
Browsing", to get past the initial dialog, and immediately start typing
something into the url bar. This shows me Yahoo! as my default.

If I repeat the above steps, but wait several seconds before typing into
the url bar, Google is shown to be my default.

Comment 5

[Mark Finkle (:mfinkle) (use needinfo?)]

Looking at Telemetry [1], we see that SEARCH_SERVICE_COUNTRY_FETCH_TIME_MS can take a few seconds in Fennec.

[1] http://mzl.la/1DvW93o

Comment 6

[Mark Finkle (:mfinkle) (use needinfo?)]

(In reply to Mike Conley (:mconley) - Needinfo me! from comment #4)

> If I repeat the above steps, but wait several seconds before typing into
> the url bar, Google is shown to be my default.

What about just re-opening the awesomescreen (tap in URL bar and type)? Is Google now shown? Is it only the very first run that shows Yahoo?

Comment 7

[Aaron Train [:aaronmt]]

I think it is a race too. I just ran into the same thing over office wi-fi, I opened the awesome-screen very quick after first-run and got Yahoo, on next browser launch I had Google

Comment 8

[Mike Conley (:mconley) (:⚙️)]

(In reply to Mark Finkle (:mfinkle) from comment #6)
> (In reply to Mike Conley (:mconley) - Needinfo me! from comment #4)
> 
> > If I repeat the above steps, but wait several seconds before typing into
> > the url bar, Google is shown to be my default.
> 
> What about just re-opening the awesomescreen (tap in URL bar and type)? Is
> Google now shown? Is it only the very first run that shows Yahoo?

So once I enter that initial state where Yahoo! is my default, it won't change back for the remainder of my session regardless of how long I wait.

If I restart my session, I get Google, just like AaronMT.

Comment 9

[Mark Finkle (:mfinkle) (use needinfo?)]

(In reply to Mike Conley (:mconley) - Needinfo me! from comment #8)

> So once I enter that initial state where Yahoo! is my default, it won't
> change back for the remainder of my session regardless of how long I wait.
> 
> If I restart my session, I get Google, just like AaronMT.

This is good to know. Thank you both for testing.

I wonder if we are caching the list in Java-side somewhere. We'll look, but in any case, I think we are at a "not a blocker" for Yahoo in Fx36.

Do others agree or disagree?

Comment 10

[Mark Hammond [:markh] [:mhammond]]

tl;dr - this sound like it is working exactly as intended (for better or worse), and probably doesn't need to block anything.

I wrote most of this in an email, but I'll copy it here for posterity:

1) If we don't already know your countryCode, then as the search service initializes it kicks off an XHR request for a geoip lookup. This can take a number of seconds.

2) If we need to know the default search engine (eg, because we are searching) before that geoip has completed, we fallback to a simple "timezone" check for this initialization - which Canada is going to match as a false-positive for the US, so Canadian users will see Yahoo.  This default remains for this session, but is not persisted anywhere - the next session will re-initialize by restarting at (1)

3) At some point our geoip request will succeed.  That is likely to be in this same session, but possibly *after* (2) has been done.  Thus, although we have fallen back to a timezone check in this session, we will probably have had the geoip request succeed after (2), and so will write the countryCode pref. That will have no impact on *this* session, but on restart when we go back to (1), we will have a countryCode and that session (and all future sessions) will see correct defaults and will not perform geoip requests.

(In reply to Mark Finkle (:mfinkle) from comment #2)
> In :mconley's case the browser.search.countryCode and the
> browser.search.region were set to the correct value, but the awesomescreen
> was using the wrong engine, right? Was the Settings > Customize > Search
> default set to the wrong value too?

This is somewhat expected - (2) forced the timezone check, but (3) completed not long after. Thus, in this session, the countryCode pref is correct, but the default search engine did not use it - only after a restart will the countryCode pref be used to determine the defaults.

(In reply to Mike Conley (:mconley) - Needinfo me! from comment #8)
> So once I enter that initial state where Yahoo! is my default, it won't
> change back for the remainder of my session regardless of how long I wait.
> 
> If I restart my session, I get Google, just like AaronMT.

Again, this is somewhat expected.

Our best bet going forward is to use platform APIs to determine the country code instead of the timezone check - that will still leave some people with the same problem, but hopefully far less than the timezone check does.

Note too that we probably could change the default in this session once the geoip completes, but Gavin and I felt that this was more jarring than waiting until the next session - but I think we'd be open to arguments that we made the wrong call there.

Comment 11

[Richard Newman [:rnewman]]

(In reply to Mark Finkle (:mfinkle) from comment #9)

> I wonder if we are caching the list in Java-side somewhere.

We do. The search engine list is only loaded once (unless you have switched locales since your last search).

        if (mSearchEngines.isEmpty() || !Locale.getDefault().equals(mLastLocale)) {
            GeckoAppShell.sendEventToGecko(GeckoEvent.createBroadcastEvent("SearchEngines:GetVisible", null));
        }


https://mxr.mozilla.org/mozilla-central/source/mobile/android/base/home/BrowserSearch.java#250


We could hack around this by clearing mLastLocale after a geoIP lookup.

Comment 12

[Kevin Brosnan [Ex-Mozilla]]

In triage Margaret said she would look over this bug and make a decision about tracking.

Comment 13

[:Margaret Leibovic]

Reading through the comments here, this seems to be enough of an edge case that we don't need to track this for release, but I see 2 issues in here:

1) We fall back to the timezone to find a default engine if we need the engine before the geoIP look succeeds. In the long term, using the platform to get a country code would help us get around this bug altogether, but as long as we're doing an http request to find the country code, there's not really much we can do here.

2) We cache this result on the Java side, so the user will have that fallback search engine for their entire browsing session, even if we get back the geoIP. We could clear this cache to reduce the number of times the user sees that fallback search engine, although it's still a little weird for your search engine to change.

Comment 14

[BMO Automation]

We have completed our launch of our new Firefox on Android. The development of the new versions use GitHub for issue tracking. If the bug report still reproduces in a current version of [Firefox on Android nightly](https://play.google.com/store/apps/details?id=org.mozilla.fenix) an issue can be reported at the [Fenix GitHub project](https://github.com/mozilla-mobile/fenix/). If you want to discuss your report please use [Mozilla's chat](https://wiki.mozilla.org/Matrix#Connect_to_Matrix) server https://chat.mozilla.org and join the [#fenix](https://chat.mozilla.org/#/room/#fenix:mozilla.org) channel.