Have a fresh install or a clean profile
Have the Language and input setting set to English - US
Google's icon should be displayed in the Nav bar
Amazon's icon is displayed
After you tap "Start browsing" and dismiss the search view the correct default search engine is displayed
► Video

The Amazon engine is set after force close + resume on 79.0.0-beta.3 using the following devices:
• Google Pixel 3a (Android 10)
• OnePlus A3 (Android 6.0.1)
► Video

I didn't only see the amazon icon in the search bar but also had it set as default and Google still missing from the engines list. Once I've done a search using amazon, it stays as default even after another restart. Not 100% reproducible, maybe 1/6.
So I'd say this is still the same as https://github.com/mozilla-mobile/fenix/issues/12081
device: Pixel 4 (Android 10)
(adding these labels for tracking, but if this is an edge case, we may skip it for a release blocker, and only do this in the fast-follow release that is this current sprint)
Hmm, seems like it could be a timing issue. Does this still happen if the user doesn't restart immediately after? I think @boek investigated it briefly.
Is this something that we could retest on the 79-beta.4 build?
What do you think, @vesta0 ?
@Mugurell is this something you and your team could look at during your day?
Hi @liuche I've just re-checked this on 79.0.0-beta.4 from 7/1.
✔️ Can't reproduce on: Huawei Mate 20 Lite (Android 9)
❌ Reproducible on :
• Google Pixel 3a (Android 10)
• OnePlus A3 (Android 6.0.1)
Each time the user opens Fenix after previously closing it Amazon will get displayed.
► Video

Deleting Amazon from the Search engine will display Bing (and so on) even if the default search engine is set to Google
► Video

I also see this in Nightly for every fresh app start.
This is really interesting.
Indeed, it happens on Nightly, but we couldn't get it to reproduce on the same device(and configuration) while using a debug build.
@boek Seeing you worked on this recently, can you help tracking down the issue?
So it looks like there is a difference between the Firefox Preview Beta (PS build) and Fenix.fennec-beta (migration) builds:
Scenario 1:
Scenario 2:
*If you had Fennec installed and migrate to Fenix, this doesn't happen.
This is really interesting.
Indeed, it happens on Nightly, but we couldn't get it to reproduce on the same device(and configuration) while using a debug build.
I can reproduce the same behavior as for Nightly if configuring the debug build to use the same MLS here so the issue may be related to the region/country/language MLS returns or how we use that data.
The issue is that refreshAsync() takes too much while based on MLS we get the location aware identifiers early.
-> we get to filter fallback engines by location identifiers.
-> google-b-1-m which is only available for US is filtered out for other regions
We could come up with a simple patch to also use the fallback identifiers..
but I'm be more interested in reducing the time refreshAsync() takes to complete or somehow synchronize the code/calls/ui updates so that we won't be showing the fallback search engines too often.
We talked this over and decided that we can ship this to Beta (so that we can get the perf experiment #7795 running), but want it to be fixed for Release, so we can take it as an uplift.
One important detail is that this issue is possible due to Google having it's identifier overridden for US to be "google-b-1-m"
If using the fallback engine identifiers (on a device using English-US) but with another region (based on MLS) based engines which for Google probably use "google-b-m" the Google search engine will be filtered out.
Thought I'd be able to sync the various calls but this leads to a longer startup time, something that we wanted to avoid in the first place - (see #9935)
To avoid the issue from #9935 we are trying to be as fast as possible and use many various conditions to decide whether to use the fallback engines / identifiers or not.
"Synchronizing" the behavior on more such checks leads many times to improper combinations of engines/identifiers and even allows for the fallbackEngines to be saved in the proper localeAwareInstalledEnginesKey and so perpetually have the wrong set of engines (if loadedRegion.isCompleted and baseSearchEngines.isCompleted.not()) for the app. (Users can of course still update the engines)
What I suggest (based on Sebastian's comment - https://github.com/mozilla-mobile/fenix/issues/9935#issuecomment-617633354) is to:
Curious about your thoughts @boek
Do you think this bug is somehow related to this:
https://github.com/mozilla-mobile/fenix/issues/12117
@SS1113 that could be related, thanks for pointing that out.
Also did some light profiling with tracing methods and saw that to return the default engine on first app start (no cached values):
For getting the default engine we are calling multiple methods which check for other previous calls being completed.
With the big execution time disparity from above it's easy to see how fallback values could alter the end result.
To keep things simple I plan to "ask" MLS if it has a cached region and if so wait for the engines/default engine result based on MLS, and if not - use the fallback values.
When we get to QA, we need to make sure that this also fixes #11906 ! and if not, we'll need to find and uplift a separate fix for that.
This should be ready to test in the next Nightly.
Now, when I add custom DuckDuckGo search, it won't appears until browser restart
Steps:
Hmmm... but
Thank you. Looking into this.
@Mugurell There is also this issue on 79.0-beta6:
The difference between beta 5 & 6 is that before, the Yandex logo was only shown on the onboarding screen and disappeared when you tapped the search bar.
On EN-US I didn't see any issues.
Talked with @Mugurell and decided to create a new issue for the remaining bugs since this was already merged: https://github.com/mozilla-mobile/fenix/issues/12544
So I'll close this one.
Closing as per https://github.com/mozilla-mobile/fenix/issues/11875#event-3543896873
Most helpful comment
This should be ready to test in the next Nightly.