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.
Differential Revision: https://phabricator.services.mozilla.com/D218589
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.
Differential Revision: https://phabricator.services.mozilla.com/D218588
Also adds this as the default for mochitests, in anticipation of the day that
the implementation is supported by the computers in automation.
Differential Revision: https://phabricator.services.mozilla.com/D216475
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).
Differential Revision: https://phabricator.services.mozilla.com/D216474
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).
Differential Revision: https://phabricator.services.mozilla.com/D216473
Will be used 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.
Differential Revision: https://phabricator.services.mozilla.com/D217015
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.
Differential Revision: https://phabricator.services.mozilla.com/D218589
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.
Differential Revision: https://phabricator.services.mozilla.com/D218588
Also adds this as the default for mochitests, in anticipation of the day that
the implementation is supported by the computers in automation.
Differential Revision: https://phabricator.services.mozilla.com/D216475
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).
Differential Revision: https://phabricator.services.mozilla.com/D216474
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).
Differential Revision: https://phabricator.services.mozilla.com/D216473
Will be used 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.
Differential Revision: https://phabricator.services.mozilla.com/D217015
Each provider has different fallback behavior:
* Windows/macOS: Fallback only on error
* Gpsd/Portal: Fallback only on timeout
* Geoclue: Fallback on both
To meet all the behaviors MLSFallback got FallbackReason/ShutdownReason and report via Glean based on that.
Differential Revision: https://phabricator.services.mozilla.com/D216085
And also some log for provider selection on Linux. This gives some clue to see what's happening in geolocation when dealing with bug reports.
Differential Revision: https://phabricator.services.mozilla.com/D215906
Sorry this is not a particularly easy patch to review. But it should be
mostly straight-forward.
I kept Document::Dispatch mostly for convenience, but could be
cleaned-up too / changed by SchedulerGroup::Dispatch. Similarly maybe
that can just be NS_DispatchToMainThread if we add an NS_IsMainThread
check there or something (to preserve shutdown semantics).
Differential Revision: https://phabricator.services.mozilla.com/D190450
In the interest of keeping directory sizes down to a manageable level,
pull the new Windows utility-process geolocation code into its own
directory. (This is not yet an issue, but will become so as new
utility-process functionality is added.)
No functional changes.
Differential Revision: https://phabricator.services.mozilla.com/D169857
This method always returned GetMainThreadSerialEventTarget(). This patch
switches all callers over to use that method instead.
We can't easily switch all calls to be calls to NS_GetMainThread(), as there is
no version of that method returning a bare nsIThread* instance.
I didn't introduce one, as we may want to add a lock around mMainThread in the
future, which would require removing nsThreadManager::GetMainThreadWeak. As
this method only returns nsISerialEventTarget, it method could remain
implemented, however, by returning a statically allocated fake event target
which forwards dispatches (and QIs to nsIThread) to the real main thread.
Differential Revision: https://phabricator.services.mozilla.com/D166608
This method always returned GetMainThreadSerialEventTarget(). This patch
switches all callers over to use that method instead.
We can't easily switch all calls to be calls to NS_GetMainThread(), as there is
no version of that method returning a bare nsIThread* instance.
I didn't introduce one, as we may want to add a lock around mMainThread in the
future, which would require removing nsThreadManager::GetMainThreadWeak. As
this method only returns nsISerialEventTarget, it method could remain
implemented, however, by returning a statically allocated fake event target
which forwards dispatches (and QIs to nsIThread) to the real main thread.
Differential Revision: https://phabricator.services.mozilla.com/D166608
As of the prior patch, these are no longer needed. I removed
these with a script, then ran clang-format on the files, then
manually reverted a few unrelated changed from the formatter.
Differential Revision: https://phabricator.services.mozilla.com/D164829
In Geolocation.cpp, the call to start the geolocation device always
had HighAccuracyRequested() set to false because no callbacks were
listening. Changed to set the callbacks first, before listening.
In Android, this patch stops the use of checking for last known location
on high accuracy location requests, adjusts comparing locations,
and also streamlines the criteria for picking the best location provider.
Differential Revision: https://phabricator.services.mozilla.com/D153226
Add a Geoclue (version 2) geolocation provider.
This way Firefox can make use of multiple location sources present in the
system, from GNSS provided by a cellular modem or the current network to
location based on visible WiFi networks and 3G tower data, all while
sharing them with other applications.
This is a pure D-Bus-based implementation using a proper state machine, it
does not require any additional dependencies.
Differential Revision: https://phabricator.services.mozilla.com/D145838
Add a Geoclue (version 2) geolocation provider.
This way Firefox can make use of multiple location sources present in the
system, from GNSS provided by a cellular modem or the current network to
location based on visible WiFi networks and 3G tower data, all while
sharing them with other applications.
This is a pure D-Bus-based implementation using a proper state machine, it
does not require any additional dependencies.
Differential Revision: https://phabricator.services.mozilla.com/D145838
The Firefox in flatpak has no access to the wireless networks to determine
accurate geolocation. We have to use the location portal instead which
provides the current location based on the nearby wireless accesspoints
or other methods.
Differential Revision: https://phabricator.services.mozilla.com/D142329
The Firefox in flatpak has no access to the wireless networks to determine
accurate geolocation. We have to use the location portal instead which
provides the current location based on the nearby wireless accesspoints
or other methods.
Differential Revision: https://phabricator.services.mozilla.com/D142329
Automatically generated rewrites of all ParamTraits and IPDLParamTraits
implementations in-tree to use IPC::Message{Reader,Writer}.
Differential Revision: https://phabricator.services.mozilla.com/D140004
