Updates each client of the nsContentUtils method to get the right drag session -- the one for the widget that is currently the source or target of the drag session.
The change to nsDOMWindowUtils::DispatchDOMEventViaPresShellForTesting() supports the change to WidgetDragEvent::InitDropEffectForTests() and enabled a
large number of test fixes in the next patch.
Differential Revision: https://phabricator.services.mozilla.com/D211067
This comes back to bug 42557 and co. It only does something
half-reasonable on Windows (on macOS we just lie and make z-order
tracking be latest-active tracking), and given we don't use the special
zorder flags elsewhere I'm pretty sure we should be able to just rip
this off... On some DEs like Wayland we can't re-stack toplevel windows.
Differential Revision: https://phabricator.services.mozilla.com/D213602
`eContextMenu` event may be fired from `widget`. Therefore, different from
`ePointerClick` and `ePointerAuxClick`, they may cross the process boundary,
may be handled by APZ and may be dispatched into the DOM after a delay.
Therefore, this patch is complicated than the previous patch. This adds
* New IPC message handlers for sending/receiving a `WidgetPointerEvent`
* New `DelayedPointerEvent` class and templated `MouseInput::ToWidgetEvent`
* `PresShell::EventHandler` handles `eContextMenu` as same as `WidgetMouseEvent`
Differential Revision: https://phabricator.services.mozilla.com/D213003
This is a regression by bug 1586471.
We should use ReceiveInputEvent for all drag events on desktop.
Also, GV issue is bug 1878819 since we have to consider more when APZ
controller thread and main thread are different. But GV doesn't turn
on fission yet.
And, there is no way to add tests for native drag and drop operations.
Differential Revision: https://phabricator.services.mozilla.com/D200783
Main thread and APZ controller thread are different on GeckoView. Some
drag events cannot be converted to InputData and aren't handled by APZ.
So we need consider drag events more for GeckoView.
Differential Revision: https://phabricator.services.mozilla.com/D197329
It doesn't hold if the load event is delayed a bit, but it breaking
shouldn't change any behavior / shouldn't matter in practice.
Differential Revision: https://phabricator.services.mozilla.com/D198785
It seems unexpected that the swipe tracker would be non-null when a swipe
finishes, but there are several codepaths that can clear it, which might
conceivably fire while the SwipeFinished callback is in the queue to be
dispatched.
Note that before bug 1837226, SwipeFinished just nulled out the pointer, which
was harmless if it was already null. My patch in bug 1837226 made us start
calling a method as well, and that created a new opportunity for a null-deref
crash here if the pointer happens to be null when we reach this function.
Differential Revision: https://phabricator.services.mozilla.com/D186204
Firefox versions >= 116 only support macOS >= 10.15. Mojave is macOS 10.14. Catalina is macOS 10.15.
Also stop including unused "nsCocoaFeatures.h" in files with no macOS version checks.
Differential Revision: https://phabricator.services.mozilla.com/D185505
Fallback from SW-WR + OpenGL to SW-WR is not implemented yet. Since the fallback is not expected to be used on release.
Fallback implementation is borrowed from the fallback process of "WebRender + D3D11" and gfxVars::AllowSoftwareWebRenderD3D11() handling.
Differential Revision: https://phabricator.services.mozilla.com/D180645
This new call should generally be a no-op, since we already un-register before
we get here, i.e. before we call SwipeFinished on the widget. This new call is
just to be extra-sure we're unregistered. With this change, nsBaseWidget is
now consistent about calling Destroy before clearing its mSwipeTracker pointer.
Depends on D180240
Differential Revision: https://phabricator.services.mozilla.com/D180241
We already avoid launching the GPU process during shutdown, but shutdown
could happen after we initiated the launch and before it completes. Top
level IPDL protocols assert that we don't create them during shutdown,
so we need to be more diligent about checking for that.
Differential Revision: https://phabricator.services.mozilla.com/D175054
If we queue the SwipeEventQueue in the case where the corresponding pan-start
event was consumed by the root content APZC, we wait for a response from the
content. And if the consumed pan-start event scrolled to the edge of the scroll
container and if the new scrolled position has been reached to the content
process before we tell whether the scroll position of the scroll container is
at the edge [1], we report it back to the SwipeTracker as the event should be
an event as a start of swipe navigation gestures. Thus, once after we got a
pan-end event, we trigger a swipe navigation. It results timeouts on a test case
waiting for an APZ:TransformEnd notification which never happens due to the page
navigation.
There's also a similar race condition where a pan-start event was consumed by a
non-root content APZC. But I haven't been able to reproduce the similar case
manually so I just filed bug 1821967 for the race and I am not going to handle
the race here. Note that I haven't been able to reproduce the original race
condition manually either though.
[1] https://searchfox.org/mozilla-central/rev/2f9a79d1c4ae7090cf50d93be86ba9dc2767a733/dom/events/EventStateManager.cpp#3727-3728
Differential Revision: https://phabricator.services.mozilla.com/D172391
Make it return a margin from client area to window area, and add an
explicit function to get the size difference.
No behavior change.
Depends on D166428
Differential Revision: https://phabricator.services.mozilla.com/D166431
Move it to the mozilla::widget namespace.
Use enum classes for transparency, popup type, popup level, etc.
Mostly automated with sed, but there were a few manual changes required
as well in windows code because they relied on Atomic<TransparencyMode>
working (which now doesn't because TransparencyMode is 1 byte instead of
4 bytes).
Differential Revision: https://phabricator.services.mozilla.com/D167537
Make it return a margin from client area to window area, and add an
explicit function to get the size difference.
No behavior change.
Depends on D166428
Differential Revision: https://phabricator.services.mozilla.com/D166431
HTMLSelectEventListener changes are needed, since currently that code works somewhat by accident given that
mTime often contains totally bogus values, like PR_IntervalNow(). Those changes then reveal issues also in
browser_editAddressDialog.js.
Differential Revision: https://phabricator.services.mozilla.com/D165618
So that APZ can wait to handle the event to do overscrolling until the browser
responds that the event wasn't used for gestures.
Differential Revision: https://phabricator.services.mozilla.com/D160438
And rename mRequiresContentResponseIfCannotScrollHorizontallyInStartDirection to
mMayTriggerSwipe.
So basically once after the flag is set, we should use it.
Differential Revision: https://phabricator.services.mozilla.com/D160436
So that APZ can wait to handle the event to do overscrolling until the browser
responds that the event wasn't used for gestures.
Differential Revision: https://phabricator.services.mozilla.com/D160438
And rename mRequiresContentResponseIfCannotScrollHorizontallyInStartDirection to
mMayTriggerSwipe.
So basically once after the flag is set, we should use it.
Differential Revision: https://phabricator.services.mozilla.com/D160436
This restores the previous behavior in a somewhat more principled way.
The extensions code is still broken in multi-monitor cases, but that's a
more complicated fix.
Differential Revision: https://phabricator.services.mozilla.com/D161997
[Int]CoordTyped no longer inherits Units because otherwise
instances of [Int]IntPointTyped may get one Base subobject because
it inherits Units, and others because of BasePoint's Coord members,
which end up increasing the [Int]CoordTyped's objects size (since
according to the ISO C++ standard, different Base subobject are
required to have different addresses).
Differential Revision: https://phabricator.services.mozilla.com/D160713
When entering fullscreen and saving the original position of a window,
also save the position to which it was moved.
When leaving fullscreen, keep the window on the same screen. Restore its
_screen-relative_ position, rather than its absolute position.
Differential Revision: https://phabricator.services.mozilla.com/D153410
`HideWindowChrome(false)` may change the reported window size on Mac:
the OS menu bar appears at the top of the screen, and this will cause the
window to shrink if it was fullscreen.
This isn't a problem yet, since we don't check the window dimensions
when exiting fullscreen... but the following commit will do exactly
that. Delay calling `HideWindowChrome` until the last possible minute --
but make sure that it _does_ get called.
Since HideWindowChrome(true) does not presently change the window size
(see bug 498835), no functional changes.
Differential Revision: https://phabricator.services.mozilla.com/D154469
Use desktop pixels everywhere:
- Store the old window position as a `DesktopRect`.
- Since `GetRectDisplayPix` is infallible, use the convenience getter
that hands us a `DesktopIntRect`.
- Add a helper function that wraps `Resize()` and takes any `Rect`
which uses `DesktopPixel`s.
No functional changes.
Differential Revision: https://phabricator.services.mozilla.com/D153409
David P