The cancel button is not really useful here and is probably confusing some
users, since they are pressing it anyway, and it is causing this crash. The
ideal fix would be for the Windows dialog to be modal instead of just immovable,
but it isn't.
Differential Revision: https://phabricator.services.mozilla.com/D225154
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
Since the method is deferred we need to do extra guesswork for possible
situtations where the name has changed because we don't have the
privilege to calculate the name in-line when content is deleted.
I tried to account for all cases as we have in our test coverage. I
hope that if there are edge cases they are false positives, and we are
firing extra name changes and not the opposite.
Original Revision: https://phabricator.services.mozilla.com/D223877
Differential Revision: https://phabricator.services.mozilla.com/D225716
TestDllInterceptorCrossProcess is not listed in cppunittest.toml so not
ran. Also this test and TestDllInterceptor should be able to fully run
under ccov thanks to MOZ_NOPROFILE MOZ_NOINSTRUMENT (which is also now
automatically part of MOZ_NAKED).
It would seem sometimes in Firefox 77 we regressed the ability to set the TRR
mode for a browsing context when opening a new tab.
I confirmed that this bug didn't happen in Fx 77 when setting the
`browser.tabs.documentchannel.parent-initiated` pref to `false`.
The nsIWebNavigation::LOAD_FLAGS_DISABLE_TRR is correctly passed into
CanonicalBrowsingContext, but it doesn't end up getting used.
This sets the appropriate DefaultLoadFlags for BrowsingContext
when the LOAD_FLAGS_DISABLE_TRR or LOAD_TRR_ONLY_MODE flags are present
in nsDocShellLoadState::LoadFlags()
Original Revision: https://phabricator.services.mozilla.com/D220550
Differential Revision: https://phabricator.services.mozilla.com/D225964
This change adds improved semantics to the
"Update Add-ons Automatically" menu item so that screen readers are
able to determine if the auto updates item is enabled or not.
Differential Revision: https://phabricator.services.mozilla.com/D219567
