Investigate native location API usage on Windows and consider migrating to modern Windows.Devices.Geolocation API
Categories
(Core :: DOM: Geolocation, task)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox149 | --- | fixed |
People
(Reporter: decoder, Assigned: m_kato)
References
(Blocks 1 open bug)
Details
Attachments
(1 file)
We are seeing a high amount of geolocation fallbacks [1] on Windows, with implications for cloud costs.
The primary reason is likely that we still use the ILatLongReport API [2] which was only supported on Windows 7 and is considered deprecated and unreliable on Windows 10+ [3]. We should instead use the Windows.Devices.Geolocation API [4] which has better support for various workflows that involve requesting permission from the user, etc.
According to my research, ILatLongReport still works even on Windows 10 but can behave intermittently, and it is possible that we are interpreting intermittent errors as fatal instead of ignoring them. That said, there is no guarantee that fixes to how we currently use the deprecated API will provide us with a significantly better success rate and we likely should migrate to the newer API.
When doing the implementation for the new API we should also consider collecting more fine-grained Telemetry for the various ways in which that API can fail, if that's applicable. Our current Telemetry for ILatLongReport doesn't really give us any insights why the API calls might be failing.
[1] https://dictionary.telemetry.mozilla.org/apps/firefox_desktop/metrics/geolocation_fallback
[2] https://searchfox.org/mozilla-central/rev/6e2b186c296474e032d9ae2e000b7c870396775c/dom/system/windows/location/WindowsLocationChild.cpp#120
[3] https://learn.microsoft.com/en-us/windows/win32/api/locationapi/nn-locationapi-ilatlongreport
[4] https://learn.microsoft.com/en-us/uwp/api/windows.devices.geolocation?view=winrt-26100
|
Assignee | |
Comment 1•6 months ago
|
||
|
||
Updated•6 months ago
|
Backed out for causing build bustages @WindowsRuntimeLocationChild.cpp.
|
|
Assignee | |
Comment 5•5 months ago
|
||
Passed https://treeherder.mozilla.org/jobs?repo=try&revision=1638e8cd8a335a57e59cd3ce033968719c16b482
|
|
Assignee | |
Comment 6•5 months ago
|
||
Although reverted fix doesn't include PWindowsLocation.ipdl that is converted from CRLF to LF. I will exclude it when re-landing this since I confirm to sheriff that it is OK.
|
||
Comment 8•5 months ago
|
||
| bugherder | ||
|
||
Comment 10•5 months ago
|
||
Makoto, your patch seems to be activating a feature on the nightly channel, is a Nightly release note needed?
|
|
Assignee | |
Comment 11•5 months ago
|
||
(In reply to Pascal Chevrel:pascalc from comment #10)
Makoto, your patch seems to be activating a feature on the nightly channel, is a Nightly release note needed?
Yes, "On Windows, Firefox will use modern Windows.Devices.Geolocation API for geolocation instead of Windows 7 location API."
|
|
||
Comment 12•5 months ago
•
|
||
Added to Firefox Nightly 149 release with this wording:
Starting with Firefox 149, on Windows, Firefox will use the modern
Windows.Devices.GeolocationAPI for geolocation instead of Windows 7 location API.
The note will be part of the Nightly release notes for 3 cycles (149-151).
When we extend the support to the release channel, a new release note request will be needed.
|
||
Comment 13•4 months ago
|
||
@Makoto, could you file a bug for letting this ride the trains so we can track it?
|
|
Assignee | |
Comment 14•4 months ago
|
||
(In reply to Haik Aftandilian [:haik] from comment #13)
@Makoto, could you file a bug for letting this ride the trains so we can track it?
I filed it as bug 2016291.
|
||
Updated•3 months ago
|
|
||
Comment 15•3 months ago
|
||
Removed from the nightly only release notes since it was enabled by default under Bug 2016291
Description
•