Open Bug 1968585 Opened 3 months ago Updated 1 month ago

Fenix makes three location services calls before the applink startup url request

Categories

(Firefox for Android :: General, task)

All
Android
task

Tracking

()

People

(Reporter: acreskey, Unassigned)

References

(Blocks 3 open bugs)

Details

In the Fenix Applink startup scenario (a user clicks on a link and Fenix is launched with that url) we see three very early location services network requests that end up competing for event queue and network link priority with the intended navigation request.

For example, in this profile, https://share.firefox.dev/45qB3Gc, we see the following:

Three simultaneous requests to

https://location.services.mozilla.com/v1/country?key=faketoken
https://location.services.mozilla.com/v1/country?key=faketoken
https://location.services.mozilla.com/v1/country?key=faketoken

And after that the target url,

https://theme-crave-demo.myshopify.com/

is loaded.

We could improve Fenix applink startup performance by deferring these requests - perhaps until after the browser startup after idle tasks have finished?
Coalescing the three requests would also be helpful.

Summary: Fenix makes three location services calls before the applink startup url → Fenix makes three location services calls before the applink startup url request

I've only seen these "faketoken" requests in Try builds, not in Firefox Nightly builds from the Android Play Store.

I'm curious how exactly the build type affects whether we make these requests.

(In reply to Markus Stange [:mstange] from comment #1)

I've only seen these "faketoken" requests in Try builds, not in Firefox Nightly builds from the Android Play Store.

I'm curious how exactly the build type affects whether we make these requests.

Oh, good point Markus -- looking at a new Play Store build I see the following early requests (the target shopify url is load 12)

https://share.firefox.dev/4jno8Z5

We've since fixed the very early calls to http://detectportal.firefox.com/success.txt?ipv4 in bug 1956081

So location services doesn't seem to be an issue in release builds, while other requests are.

Hi Mark, do you know what these requests are for and what causes the difference between try builds and play store nightlies? Is this related to bug 1929411?

Flags: needinfo?(standard8)

Thanks for the needinfo, for a couple of weeks I've suspected there may be more than one request, but I hadn't got around to verifying it. They may only happen on a fresh profile though - is that what we could be seeing here and why comment 0 and comment 2 are different?

As regards to where these might be coming from:

  • Region.sys.mjs
    • This is the toolkit Region service, it checks initially on first startup of a new profile, and then approximately once every 7 days thereafter.
    • Generally it triggers as soon as it is requested, as it is helpful for things like the search service (although it isn't used on Android), to get the region as soon as possible. Though if we do the suggestion in bug 1951731 for trying the region from the OS, then that might be able to cut down some situations (though maybe desktop-only situations).
    • I'm not sure where it is exactly that Android is using Region.sys.mjs. I suspect it is some of the toolkit modules, maybe suggest, but I think someone on the Android team will need to track that down, as I'm not sure how.
  • There's also an Android specific Kotlin code MozillaLocationService that is doing something similar to the region component that does something similar to the toolkit Region service.

I'm not sure though why we would be getting three requests, when we've only got two modules. I think Roger has worked in the area, but if not maybe he knows who to ask, so I'll pass the NI on.

With respect to having two region services, I've been thinking about forming a Rust component in application services that could potentially be shared across platforms (iOS could do with something as well). I don't yet know the practicalities of it, but it might avoid the issues here.

Flags: needinfo?(standard8) → needinfo?(royang)
Severity: -- → S3
Flags: needinfo?(royang)

The Bugbug bot thinks this bug should belong to the 'Firefox for Android::Search' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Component: General → Search
Component: Search → General
You need to log in before you can comment on or make changes to this bug.