1803600 - navigator.geolocation.getCurrentPosition slow or timeout

Status: VERIFIED FIXED

(GeckoView :: General, defect, P1)

Description

[Bastian]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:107.0) Gecko/20100101 Firefox/107.0
Firefox for Android

Steps to reproduce:

I have a php / javascript based web-application that is running since years very well.

On some pages I am using geolocation, mainly on Android-smartphones. Nothing has been changed, in this year.

Additional Informations:

My location: Darmstadt / Germany.

The issue is tested on 2 android smartphones and a PC.

The geolocation in Firefox on the pc is normal fast, less than 5 seconds.

Actual results:

Since some weeks only in Firefox (Standard, Beta and Nightly) the geolocation is very slow or I get a timeout.
The timeout-option is set to 60 sec.

The application has no problems on Chrome, Opera, DuckDuckGo or the MI-Browser from Xiaomi, so I am sure that will be a bug in Firefox 107.2.0 for Android and not in my Application.

Expected results:

Get the position in less than 5 seconds.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Core::DOM: Geolocation' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[Bastian]

Is there nobody that know how for this issue ?

Comment 3

[Kris Maglione [:kmag]]

It would seem to be an issue with the Android geolocation backend. The most likely recent change that looks relevant is bug 1765835, which would presumably make the results slower if you're using high accuracy mode. But bug 1771229 is more likely if it showed up on all channels at once, since that was uplifted when it landed.

S2 for now, but S1 if more people can reproduce. I have personally not experienced this.

Comment 4

[Bastian]

Can be, but I do not believe it.

In the case that the issue will be a problem of the android geolocation backend than all browser must have
the same problem, I am believe.

But of 5 tested browsers only FireFox (all Android-Versions) is slow or get timeouts.

The timeouts come only if I am near a building with WLAN-Routers. If I stay in a free area far away from
buildings than the geolocation will be slow (ca. 10 to 30 seconds), but successful, with no timeouts.

And the problems I have only since some weeks, so I beliebe that FireFox is changing something in this
area in one of the last updates.

Comment 5

[Olivia Hall [:olivia]]

Hi Bastian, thanks for the bug report!

Could you give us a few additional details to help us reproduce the bug?:

• Android version and device manufacturer
• Website example or sample geolocation JavaScript code that causes a timeout

Thanks for the WLAN-Routers detail too and the info on what versions of Firefox you tried.

Bug 1765835 that Kris mentions seems the most related to me too. We also have bug 1790405 to fix slower callbacks in watchPosition on Android.

Comment 6

[Bastian]

FireFox: 107.2.0 Build: #2015918523

Xiaomi Redmi Note 8 Pro / Android 11 RP1A.200720.011 / MIUI Global 12.5.8
Xiaomi Redmi Note 11 / Android 11 RKQ1.211001.001 / MIUI Global 13.0.14

WLAN-Router: AVM FritzBox 7490 / FRITZ!OS: 07.29

To give a website-example is not so easy, because you have to register
your smartphone in my ERP-System in a german dialog.

I use geolocation for setting timestamps of work for my employees.

var GeoLocationOptions = {
enableHighAccuracy: true,
timeout: 60000,
maximumAge: 0
};
navigator.geolocation.getCurrentPosition(GeoLocationSuccess, GeoLocationError, GeoLocationOptions);

I'm also use watchPosition:

var Watch = 0;
var WatchId = -1;
var WatchDo = 5;
var WatchLevel = 20;
var WatchSleep = 10; // Sekunden
function GeoLocationWatch() {
alert('GeoLocationWatch: aktiv.');
WatchId = navigator.geolocation.watchPosition(GeoLocationSuccess, GeoLocationError, GeoLocationOptions);
}
function GeoLocationSuccess(position) {

. . . . some commands . . . .

     if (Watch <= WatchDo) {
         if (position.coords.accuracy > WatchLevel) {

// alert('a. Watch: ' + Watch + '. (' + WatchId + ') Genau: ' + NumberFormatG(position.coords.accuracy, 2) + ' m');
Watch = Watch + 1;
GeoLocationWatch();
return;
} else {
// alert('b. Watch: ' + Watch + '. (' + WatchId + ') Genau: ' + NumberFormatG(position.coords.accuracy, 2) + ' m');
Watch = Watch + 100;
Post = Watch;
navigator.geolocation.clearWatch(WatchId);
}
} else {
// alert('c. Watch: ' + Watch + '. (' + WatchId + ') Genau: ' + NumberFormatG(position.coords.accuracy, 2) + ' m');
Post = Watch;
navigator.geolocation.clearWatch(WatchId);
}

. . . . some commands . . . .

}

Comment 7

[Bastian]

Correction:
After some more test I have to say that the timeouts has not really something to do with the WLAN-Router.

The reason will be more the place of the room I am staying. Near to the street or ca. 10 to 15 m away from the
street.

If I stay in my office in back of the house I get the timeouts.

If I stay in the guest-room near the street the geolocation will be slow, but successful.

But all the other browsers has no problems in my office-room.

I am installing some browsers more, Vivaldi, Samsung, Brave and Tor.

Tor does not get any geolocation, that is clear why. All the others have no problems and all of them
very fast in geolocation, less than 2 seconds.

Comment 8

[Bastian]

watchPosition: to disable it does not help.

Comment 9

[Olivia Hall [:olivia]]

Thanks for all of the info!

It does look like bug 1765835 to enableHighAccuracy could be causing this change in behavior based on the code snippet.

Before that bug fix, enableHighAccuracy was using cached locations and not fetching new locations each time (accuracy flag not setting). This process should be updated to be quicker to align with other browsers.

Comment 10

[Bastian]

Thanks for your message, but I do not really understand what you want to say.

Can be that my english is to bad.

Have I something to do, to fix the problem in my script ?
'
Have you something to do in FireFox and a comming update will bring
a bugfix for this issue ?

Should I change my standard browser to one of the others to get a stable
use of my script ?

Comment 11

[Kris Maglione [:kmag]]

(In reply to Bastian from comment #10)

Have you something to do in FireFox and a comming update will bring
a bugfix for this issue ?

This one. We need to update our geolocation code to provide similar high accuracy performance to other browsers. Hopefully bug 1790405 will do that.

Have I something to do, to fix the problem in my script ?

It is possible that you could tweak some settings to get better performance, but it would depend on your exact requirements.

Comment 12

[Bastian]

Thanks for your replay.

I hope the bugfix will coming soon.

This bug is a problem for me and my employees, at each day.

Comment 13

[Garrett Boone]

I'm here while troubleshooting mobile 108.1.0 which is behaving differently than desktop Developer Edition 109.0b7 (64-bit) with regards to getCurrentPosition. Mobile was working fine last night and this morning with default GeoLocationOptions, but does not work now suddenly, with no changes. No updates have been performed on any apps.

I am noticing that even when Allow is saved on mobile, and the blue dot appears, subsequent page refreshes with:

navigator.permissions.query({ name: 'geolocation'}).then((result) => {
    console.log(result);
})

are showing "prompt" instead of "granted". Timeout option with 60000 is not respected and location icon (security feature) on device disappears after 5 seconds.

I'm running LineageOS 19-20221220-microG-lake on Moto G7 Plus device.

Comment 14

[Garrett Boone]

(In reply to Garrett Boone from comment #13)

with no changes. No updates have been performed on any apps.

I realize now that I restarted my device two hours ago. This may have something to do with the change. I last restarted the device one week ago after the upgrade in LineageOS.

Comment 15

[Garrett Boone]

I removed the Mozilla UnifiedNLP Backend permissions, restarted device, and then re-granted Location permissions to the same, and it's working again. I can now see that the state is "prompt" and then "granted" automatically without user interaction, when Allow is saved.

Comment 16

[Olivia Hall [:olivia]]

Thanks for the bug report, Garrett! We are tracking a LineageOS bug over at bug 1799485 that might be more applicable or relevant.

Just to confirm, geolocation requests started working on LineageOS again after removing and re-granting the app's overall location permissions?

Comment 17

[Garrett Boone]

I will post an update on 1799485 as that fits my scenario exactly.

Comment 18

[Bastian]

Hello to all,

is something happen in the case of this bug ?

I tried with FireFox-Standard, -beta, -Nightly. The bug still exists.

The browser Chrome, DuckDuckGo, Vivaldi, Samsung and Brave have no problems
to get a geolocation in less than 2 seconds.

FireFox also has a problem, if I stay in a room some meters away from the street.

Comment 19

[Olivia Hall [:olivia]]

I think removing this check that was added in bug 1765835 might revert to the prior behavior and speed up the location request. That change shouldn't impact highAccuracy behavior too much because part of the issue in bug 1765835 was the high accuracy flag was never setting. Bug 1790405 looks into more general ways to speed up the requests too, but simply removing that flag might correct the regression for now.

Comment 20

[Bastian]

After removing the Flag highAccuracy I get the geolacation result fast,
like the other browsers.

At the first look the accuracy itself is moderate, ca. 50 m away.

In my opinion the removing of the flag by the user can not be a good
solution.

It will be a better way that the flag can be still stay and FireFox will be ignore
this flag as long the function after this flag is not stable.

Comment 21

[Garrett Boone]

I just updated my device to LineageOS 20 and while making sure that the microg Mozilla Location Services were disabled, and while FF 109.1.1 was granted Location permissions, even high accuracy, it seems to be working again for me. The timing of the location found is on par with other apps. I would have to conclude in my case that the OS update is what has caused this change.

In addition to my own web app functioning properly, I tested with https://developer.mozilla.org/en-US/docs/Web/API/Geolocation_API/Using_the_Geolocation_API

Comment 22

[Bastian]

After some tests I figured out that it is not necessary to remove
the flag highAccuracy.

The flag can be stay still, if it will be set to false.

Comment 23

[Olivia Hall [:olivia]]

Attachment: Bug 1803600 - Android Geolocation High Accuracy Timeout

In Bug 1765835, some adjustments were made to improve high accuracy on
Android. One of those changes made Android to always pull a new location
and not use a “last known location” on high accuracy requests. It seems
on some devices, require a new location can lead to long timeouts.
This bug reverts that change back to the prior behavior.
(High location is still improved because part of the issue in the other
bug was a Gecko callback not occurring.)

Comment 24

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/5cff588fab65
Android Geolocation High Accuracy Timeout r=geckoview-reviewers,m_kato

Comment 25

[Norisz Fay [:noriszfay]]

https://hg.mozilla.org/mozilla-central/rev/5cff588fab65

Comment 26

[Bastian]

In my case is not fixed in FireFox Nightly V. 113.0a1 !

Comment 27

[Olivia Hall [:olivia]]

Thanks for testing, Bastian. Could you confirm the full GV nightly version where this landed recently? Is the behavior the same or is there any improvement?

(e.g., GV: 113.0a1-20230323211910 Nightly would be the first version with the update present.)

Comment 28

[Bastian]

In my case is not fixed in FireFox Nightly V. 113.0a1-20230322211554

Comment 29

[Ryan VanderMeulen [:RyanVM]]

Comment 28 shows an older build than comment 27 says would have the fix. Can you please try testing again with a newer one?

Comment 30

[Bastian]

In my case appears ok in FireFox Nightly V. 113.0a1-20230326214700

In FF beta and FF standard the versions are less then V 113.0
and still not fixed.

Comment 31

[Bastian]

How long have I to wait for FF standard V 113.0a1 ?

Comment 32

[BugBot [:suhaib / :marco/ :calixte]]

The patch landed in nightly and beta is affected.
:olivia, is this bug important enough to require an uplift?

• If yes, please nominate the patch for beta approval.
• If no, please set status-firefox112 to wontfix.

For more information, please visit auto_nag documentation.

Comment 33

[Olivia Hall [:olivia]]

Comment on attachment 9324291 [details]
Bug 1803600 - Android Geolocation High Accuracy Timeout

Beta/Release Uplift Approval Request

• User impact if declined: Timeouts will be more common for JavaScript high accuracy location requests on certain devices on Android.

This patch allows Android to use a recent prior location instead of requiring it to fetch a new location each request on high accuracy requests. (This reverts a portion of the code to a prior behavior before the regression.)

• Is this code covered by automated tests?: Yes
• Has the fix been verified in Nightly?: Yes
• Needs manual test from QE?: No
• If yes, steps to reproduce: Go to a website on Android that requests a high accuracy location on an impacted device, such as some Xiaomi devices, without a clear view of the sky/low signal.
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): This change is not overly risky because it is small patch and is a partial reversion to a prior behavior. Most of the risk would be around impacting geolocation accuracy on Android.
• String changes made/needed: No
• Is Android affected?: Yes

Comment 34

[Dianna Smith [:diannaS]]

Comment on attachment 9324291 [details]
Bug 1803600 - Android Geolocation High Accuracy Timeout

Approved for 112.0b8

Comment 35

[Dianna Smith [:diannaS]]

https://hg.mozilla.org/releases/mozilla-beta/rev/f0dd2c58d8e9

Comment 36

[Delia Pop (Android QA)]

Tested on latest Nightly 113.0a1 from 03/29 and Beta 112.0b8 on several websites that requested access to geolocation, and no issues were observed.
Devices used:

• Xiaomi 12 Pro (Android 13)
• Xiaomi Redmi Note 8T (Android 11)
• Huawei MediaPad M2 (Android 5.1.1)
• RealMe GT Master Edition (Android 11)