This prevents a problem where Content Analysis responds synchronously (because
the site is on the deny list), which causes a modal window to pop up, which
cancels the drag session. This causes MOZ_ASSERTs() where we expect the drag
session to still be active.
Original Revision: https://phabricator.services.mozilla.com/D222668
Differential Revision: https://phabricator.services.mozilla.com/D227594
getURIForDropEvent delegates to getURIForBrowsingContext -- the ground truth for
CA URIs.
This also adds a check that getURIForDropEvent is correctly called in CA tests.
We do not yet test that it returns the right value -- that is future work.
Original Revision: https://phabricator.services.mozilla.com/D222192
Differential Revision: https://phabricator.services.mozilla.com/D227592
This fixes four issues:
1. The test didn't provide enough movement to generate a drag session on the
source before moving to the target. This meant that, when they were in
different windows, Gecko wouldn't send dragleave to the source or dragenter
to the target. It also never sent dragenter to the source in the first
place. This remedies that.
2. dragenter and dragleave weren't properly handled because the test was sending
dragleaves instead of dragexits (the latter being what Gecko expects and the
former being synthesized from that -- see e.g. nsNativeDragTarget::DragLeave).
This now uses dragexits and sets the proper expectations.
3. expectProtectedDataTransferAccess was needlessly complicated and, after #1,
gave the wrong answers for some events like dragenter called on the source.
4. The event handler wasn't checking for exceptions and the drop handler was
intentionally causing one, which was causing it to miss the rest of its
execution.
Original Revision: https://phabricator.services.mozilla.com/D219550
Differential Revision: https://phabricator.services.mozilla.com/D227589
Sends OOP drop events to content analysis for approval before sending them to
the DOM. It intercepts drop events at the browser level and sends them to CA
before calling stopPropagation and preventDefault on them. (CA also presents a
modal dialog over the tab.) The drag session then ends as usual in the parent
process but remains open on the related browser in the process where it would be
sent to the DOM while the drop is being analyzed. While CA runs, the browser
dispatches an eQueryDropTargetHittest event to locate the drop target while the
event screen coordinates are still valid. When CA is complete, a drop or
dragexit event is sent to the drop target (drop if it was approved by CA). Calls
to EndDragSession are delayed during this.
Differential Revision: https://phabricator.services.mozilla.com/D227587
Previously, we had relied on macOS eventually invoking the
windowDidEnterFullscreen and windowDidExitFullscreen delegate methods.
But in cases where macOS does not, and instead invokes the "fail"
methods, we can do the right thing to put the nsCocoaWindow in a
synchronized state with the DOM.
Differential Revision: https://phabricator.services.mozilla.com/D227295
This patch allows us to download Widevine updates directly from the
Chromium update service, bypassing balrog and fallback configuration
options. This will be useful in the early stages of testing Widevine
updates, allowing us to use whatever Google has pushed to its own users,
including beta updates, before we engage release engineering.
Relevant Widevine L3 prefs have been added:
- media.gmp-widevinecdm.force-chromium-update
- media.gmp-widevinecdm.force-chromium-beta
which force the use of the Chromium update service, and requesting beta
versions (if available) respectively.
Similarly, Widevine L1 prefs have been added as well:
- media.gmp-widevinecdm-l1.force-chromium-update
- media.gmp-widevinecdm-l1.force-chromium-beta
Original Revision: https://phabricator.services.mozilla.com/D223017
Differential Revision: https://phabricator.services.mozilla.com/D227229
`adoptFromWindow` sets the sidebar width based on the "opener" window. If the opener
does not have a sidebar, no width is remembered. Previously, flipping the sidebar revamp
pref required opening a new window to see the revamped sidebar, and hence meant the opener
did not have a sidebar.
This patch ensures the revamp is applied in the current/opener window and hence the width
of the sidebar opened in that window is used to determine the width of the sidebar in future
windows opened. This should resolve the issue some users have found when closing the browser
via the X button and reopening the browser doesn't remember the sidebar width.
Differential Revision: https://phabricator.services.mozilla.com/D226942
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
