1900225 - Improve geolocation dialog response on Windows

Status: RESOLVED FIXED

(Core :: DOM: Geolocation, task)

Description

[David Parks [:handyman]]

Microsoft is changing the behavior of permissions around wifi scans that will affect the way the browser's GLS geolocation fallback service appears to the user. Their plan is here. It will tie the wifi scanning APIs to geolocation permissions, making the MLS/GLS geolocation fallback unavailable if the user has blocked location, which means the fallback will be almost useless on Windows [*] -- users will have to grant geolocation permission to get useful results. Note that these changes refer to a coming version of Windows (2024H2) and can currently only be seen in Windows Canary builds.

The first time (or intermittently?) Windows blocks geolocation (or wifi-scanning for geolocation), Windows will present the user with a dialog asking if they wish to enable geolocation for the application. This dialog will come after the Firefox dialog where the user will have already granted geolocation permission to the web page, so this is redundant. This bug adds a notice about the coming redundant dialog to the Firefox dialog. Again, this dialog will be intermittent and may only appear the first time geolocation is blocked (it will always appear the first time).

Also, since the wifi scanning is implicitly blocked in all use cases (because wifi-scanning is blocked if geolocation is blocked, and we only do wifi-scanning for geolocation), the user granting geolocation permission to the page is a bit silly and, if geolocation is blocked by Windows, the results they get will be terrible, if they get any results at all. Therefore, this patch checks for the setting (if it can [**]) before asking the user to grant geolocation permission to the page. It does this without actually requesting geolocation (which would be a violation of the user's security and could incorrectly trigger the aforementioned one-time dialog). If geolocation isn't available then the Firefox dialog will additionally tell the user that they will need to grant geolocation permission to Firefox and, if they approve geolocation for the page, it will open system settings to geolocation for them and wait (with a modal dialog) until they grant the permission, which it will automatically detect and remove the dialog. Note that the modal dialog has a "cancel" button, in case the user changes their mind.

--

[*] The fallback still allows IP geolocation lookup, so it's not useless but the quality of the results is obviously subject to a lot of external factors.
[**] The APIs for this are only connected for Windows and this behavior isn't implemented in pre-2024H2-Canary builds. On old Windows and on other platforms, this functionality is a no-op -- Firefox (and Windows) will behave as they do now. We have future plans to implement this for Macos, which also seems to provide the necessary APIs for this behavior.

Comment 1

[David Parks [:handyman]]

Attachment: Bug 1900225: Part 1 - Make dismissPrompts accessible in the prompt service r=gijs!

Moves code into the prompt service so it can be reused.

Comment 2

[David Parks [:handyman]]

Attachment: Bug 1900225: Part 2 - Inform user of system UX issues initiated by geolocation request r=gstoll!,emilio!

This patch installs the framework for various platforms to inform the user of
one of two things: 1) a coming system dialog asking for system geolocation
permission that will be presented after the Firefox doorhanger asking for
permission for the page, and 2) that we will open a system preferences window,
where the user can enable geolocation for Firefox because it is currently not
enabled. The code that handles this has been remoted to the parent process
since implementations will not be able to operate in the content process
sandbox.

Here, it stubs the behavior so this does nothing on every platform.
In this patch series, the behavior will be implemented for Windows.

Note: The code will run the geolocation for the page if the user granted it in
Firefox, regardless of whether the user granted or canceled the system
permission. This respects the user's instruction and provides a work-around in
the event of a bug, although it would usually either fail to get a location or
it will get a very poor one (e.g. via IP lookup).

Comment 3

[David Parks [:handyman]]

Attachment: Bug 1900225: Part 3 - Implement system geolocation permission UX on Windows r=#win-reviewers!

This implements PresentSystemSettings, LocationIsPermittedHint and
SystemWillPromptForPermissionHint for Windows. The Windows APIs are not always
available -- some are currently only available in Windows 11 Canary builds
(slated for September release). In the event that APIs are not available, this
should do nothing. At present, this is detailed here:

https://learn.microsoft.com/en-us/windows/win32/nativewifi/wi-fi-access-location-changes

There are two issues that this is intended to handle:

1. The system will display a one-time (or so) dialog to the user when Firefox
   requests geolocation but doesn't have permission. For that case, we inform the
   user that they will be asked to grant location permission again. This system
   dialog is only presented in versions of Windows that support all of the relevant
   APIs.

2. We open system settings to the right page and post a cancelable modal dialog
   on the tab if the user grants geolocation to the page but geolocation permission
   isn't currently granted in the OS. This case will not happen if case #1 did.
   Unfortunately, we can't get information about the permission status without a
   location request on old versions of Windows, so this also does nothing unless
   the recent APIs are supported (in this case, AppCapability::CheckAccess).

This work is necessitated not only by the new (occasional) system dialog but
also by Microsoft's plans to block wifi scanning if geolocation isn't available.
We have used wifi scanning as part of a fallback when system geolocation isn't
available -- that approach is no longer viable here. A user would confusingly
get repeated errors or very poor results (e.g. IP lookup results) without
information as to why, if that happened. This is what happens in the current
Windows Canary build if system geolocation is turned off. The fallback remains
useful on other platforms, although Linux is in flux (but it is not in the
scope of this bug).

Comment 4

[David Parks [:handyman]]

Attachment: Bug 1900225: Part 4 - Add geo.prompt.open_system_prefs to block opening system preferences r=gstoll!

Also adds this as the default for mochitests, in anticipation of the day that
the implementation is supported by the computers in automation.

Comment 5

[David Parks [:handyman]]

Attachment: Bug 1900225: Part 1 - Add dismissPrompts to Windows geolocation UI utils r=gijs!

Will be used on Windows later in this series to remove a cancel dialog that is
presented over a tab while Gecko waits for the user to grant geolocation
permission in the OS.

Comment 6

[David Parks [:handyman]]

Attachment: Bug 1900225: Part 5 - On Windows, do not show message about wifi scan permission if no wifi is present r=#win-reviewers!,#necko-reviewers!

We added a note to the geolocation doorhanger, warning the user when Windows is
going to repeat the request for user permission (although it asks for permission
for Firefox, not for the web page). However, Windows won't do this if there is
no wifi adapter that could perform the scan. Here, we avoid adding the note in
that case.

Comment 7

[David Parks [:handyman]]

Attachment: Bug 1900225: Part 6 - Wait for Windows permission dialog to be dismissed before requesting geolocation r=#win-reviewers!,emilio!

When Windows presents the dialog asking the user to give geolocation permission
to Firefox, we need to wait for the user to make a choice before running the
geolocation request. Previously, we were not waiting for the user's response
so most requests would timeout and fail, even if the user replied "Yes".

This dialog is only ever presented once -- the first time that Firefox asks
Windows for a wifi scan. It does not reappear on restarts or reinstalls. This
dedicated Yes/No system prompt is a bit more user-friendly than system settings.

This "system will prompt for permission" case could be completely avoided since
wifi scanning is not useful to us when it requires geolocation permissions as
geolocation would override it. We would need the MLSFallback behavior to skip
scanning wifi when geolocation permission wasn't already granted, or else the
MLSFallback would present the system prompt in question, despite the user having
already denied permission. On the other hand, we need the old scanning behavior
for this case when running versions of Windows 10 and 11 that don't have these
updates. (The updates are set to appear in the 24H2 version of Windows 11.)
This approach avoids that kind of version special-casing.

Comment 8

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/35a1d931e407
Part 1 - Add dismissPrompts to Windows geolocation UI utils r=Gijs
https://hg.mozilla.org/integration/autoland/rev/0bdd05d6a2f0
Part 2 - Inform user of system UX issues initiated by geolocation request r=gstoll,emilio,bolsson,pbz
https://hg.mozilla.org/integration/autoland/rev/b389e47cd649
Part 3 - Implement system geolocation permission UX on Windows r=win-reviewers,gstoll
https://hg.mozilla.org/integration/autoland/rev/d9debcb16932
Part 4 - Add geo.prompt.open_system_prefs to block opening system preferences r=gstoll
https://hg.mozilla.org/integration/autoland/rev/092cece48dcd
Part 5 - On Windows, do not show message about wifi scan permission if no wifi is present r=win-reviewers,necko-reviewers,valentin,gstoll
https://hg.mozilla.org/integration/autoland/rev/2c0d4dc4c52e
Part 6 - Wait for Windows permission dialog to be dismissed before requesting geolocation r=emilio,win-reviewers,gstoll

Comment 9

[Sandor Molnar[:smolnar]]

Backed out for causing build bustages @ GeolocationSystemWin.cpp

Backout link: https://hg.mozilla.org/integration/autoland/rev/b42c436181f018e1f177867acbb515fa1c4b3244

Push with failures

Failure log -> /builds/worker/checkouts/gecko/dom/geolocation/GeolocationSystemWin.cpp:16:10: fatal error: 'windows.security.authorization.appcapabilityaccess.h' file not found

Comment 10

[David Parks [:handyman]]

I'll have to stub this out for mingw. It can use the old behavior, same as versions of Windows that are too old to have the APIs.

Comment 11

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

There are some r+ patches which didn't land and no activity in this bug for 2 weeks.
:handyman, could you have a look please?
If you still have some work to do, you can add an action "Plan Changes" in Phabricator.
For more information, please visit BugBot documentation.

Comment 12

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/654127d4f46c
Part 1 - Add dismissPrompts to Windows geolocation UI utils r=Gijs
https://hg.mozilla.org/integration/autoland/rev/759490f774dd
Part 2 - Inform user of system UX issues initiated by geolocation request r=gstoll,emilio,bolsson,pbz
https://hg.mozilla.org/integration/autoland/rev/475298cc118a
Part 3 - Implement system geolocation permission UX on Windows r=win-reviewers,gstoll
https://hg.mozilla.org/integration/autoland/rev/a4a3ff203cbf
Part 4 - Add geo.prompt.open_system_prefs to block opening system preferences r=gstoll
https://hg.mozilla.org/integration/autoland/rev/a69afa794297
Part 5 - On Windows, do not show message about wifi scan permission if no wifi is present r=win-reviewers,necko-reviewers,valentin,gstoll
https://hg.mozilla.org/integration/autoland/rev/d6dc7bd1b4cb
Part 6 - Wait for Windows permission dialog to be dismissed before requesting geolocation r=emilio,win-reviewers,gstoll

Comment 13

[Atila Butkovits]

https://hg.mozilla.org/mozilla-central/rev/654127d4f46c
https://hg.mozilla.org/mozilla-central/rev/759490f774dd
https://hg.mozilla.org/mozilla-central/rev/475298cc118a
https://hg.mozilla.org/mozilla-central/rev/a4a3ff203cbf
https://hg.mozilla.org/mozilla-central/rev/a69afa794297
https://hg.mozilla.org/mozilla-central/rev/d6dc7bd1b4cb

Comment 14

[Gian-Carlo Pascutto [:gcp]]

Rollout of the affected Windows versions has started today: https://support.microsoft.com/en-us/windows/inside-this-update-93c5c27c-f96e-43c2-a08e-5812d92f220d

Comment 15

[David Parks [:handyman]]

We were considering whether bug 1917201 should be prioritized before ESR uplift but I don't think a fix will be as easy as I'd hoped, so we probably shouldn't wait for it.

Comment 16

[David Parks [:handyman]]

Comment on attachment 9417816 [details]
Bug 1900225: Part 6 - Wait for Windows permission dialog to be dismissed before requesting geolocation r=#win-reviewers!,emilio!

ESR Uplift Approval Request

• If this is not a sec:{high,crit} bug, please state case for ESR consideration: The circumstances under which the ESR is run have changed -- the new Windows 24H2 was released last week (Sept 2024). ESR has to keep up.
• User impact if declined: Without these patches, changes to the way that Windows 11 does permissions will mean that many geolocation users will get nonsensical responses and a bad experience. In particular, users may get unexpected dialogs (like new system dialogs), may see terrible geolocation resolution in their responses (for example, if they silently fall back to IP lookup), and may just get absurd answers (for example, after they approve geolocation permission, they may be told that geolocation was not approved). These are some of the many failure cases.
• Fix Landed on Version: 131
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): It's already been released in 131 and has undergone QA testing. Bug 1917201 is the most substantial regression they found and we think it's complex and rare enough that we can address it later. The regression is a crash that only arises from strange user behavior.

Comment 17

[David Parks [:handyman]]

I may have a fix for bug 1917201 coming up, if this can wait a bit.

Comment 18

[Ryan VanderMeulen [:RyanVM]]

Comment on attachment 9413643 [details]
Bug 1900225: Part 1 - Add dismissPrompts to Windows geolocation UI utils r=gijs!

Discussing this with David further, I think the balance of issues here leans towards taking these patches on ESR128 and dealing with potential issues as they arise. One note, part 2 includes some string changes, but we picked up a newer l10n-changesets.json on ESR128 last week as part of uplifting bug 1768724, so I think we're OK there. Approved for 128.4esr.

Comment 19

[Ryan VanderMeulen [:RyanVM]]

Comment on attachment 9417816 [details]
Bug 1900225: Part 6 - Wait for Windows permission dialog to be dismissed before requesting geolocation r=#win-reviewers!,emilio!

Approved for 128.4esr.

Comment 20

[Pulsebot]

https://hg.mozilla.org/releases/mozilla-esr128/rev/59bbaf45c036
https://hg.mozilla.org/releases/mozilla-esr128/rev/c30cd4fdd410
https://hg.mozilla.org/releases/mozilla-esr128/rev/9ccd762bbf06
https://hg.mozilla.org/releases/mozilla-esr128/rev/ce367247e76e
https://hg.mozilla.org/releases/mozilla-esr128/rev/857663e36221
https://hg.mozilla.org/releases/mozilla-esr128/rev/93b7a493f984