A popup attached to a modal parent window doesn't get mouse events
from Gtk as they'are directed to the modal parent. This is usually solved
by pointer grab which that doesn't work on Wayland in our current
setup as it performs show and grab in one step.
We emulate it by setting popup as modal too but then patent
window doesn't get mouse events outside of popup (Bug 1899299).
we need to listen
Surprisingly attaching events handler to mShell fixes it
and we're getting events from both parent and popup windows.
Differential Revision: https://phabricator.services.mozilla.com/D221290
This is a simplified version of a fix authored by Steven Michaud. This
creates a death grip in DestroyNativeWindow() and holds it until the
nsCocoaWindow is destroyed. This seems to satisfy the various run loops
in macOS which might invoke DestroyNativeWindow() without holding a
reference to the window itself.
Differential Revision: https://phabricator.services.mozilla.com/D226169
This patch moves the call to BaseWindow::Destroy() and ::OnDestroy() to
the end of nsCocoaWindow::Destroy(). It adds a death grip on this before
remove this from mParent. This should keep the window in a more stable
state throughout the function scope.
Differential Revision: https://phabricator.services.mozilla.com/D216066
It is important to remove the NSTrackingArea before the nsCocoaWindow is
deallocated. This patch ensures that we remember which NSView is holding
the tracking area and remove the tracking area from that view during
dealloc (as well as whenever the tracking area is updated).
Since the `trackingAreaView` property accessor returns a value based on
`contentView` or its superview, manipulations of either view will change
the return value of the accessor. We can't rely on it being consistent
throughout the lifetime of the window. This change ensures that we will
always remove the tracking area from the view that added it.
Differential Revision: https://phabricator.services.mozilla.com/D212949
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
