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
A window is fullscreenable iff it's a desktop window (that is, a
positional child of the desktop rather than of another window) -- and
desktop windows are the windows which use desktop-pixel units in
Resize().
Code coverage confirms that the branch when `BoundsUseDesktopPixels()`
returns `false` is never taken in tests.
Under the (hopefully justified) assumption that it's never taken at all,
no functional changes.
Differential Revision: https://phabricator.services.mozilla.com/D153408
Otherwise, it changes the move-to-rect inputs, which can change the
output as well, making us move the anchor all the way to the right.
You could, I guess, consider this a mutter bug of sorts, because it
feels weird that you pass it an anchor that has been a `move-to-rect`
output and you get another rect as an output.
But also, it's kinda silly that we're doing that to begin with, so avoid
it by telling the popup frame whether it's been positioned / moved by
move-to-rect (and keeping the anchor in that case).
The reason this works on my setup without "Large text" is just dumb luck
(the front-end computes a max-height for the panel that is small enough
to fit on the screen).
Differential Revision: https://phabricator.services.mozilla.com/D155406
Otherwise, it changes the move-to-rect inputs, which can change the
output as well, making us move the anchor all the way to the right.
You could, I guess, consider this a mutter bug of sorts, because it
feels weird that you pass it an anchor that has been a `move-to-rect`
output and you get another rect as an output.
But also, it's kinda silly that we're doing that to begin with, so avoid
it by telling the popup frame whether it's been positioned / moved by
move-to-rect (and keeping the anchor in that case).
The reason this works on my setup without "Large text" is just dumb luck
(the front-end computes a max-height for the panel that is small enough
to fit on the screen).
Differential Revision: https://phabricator.services.mozilla.com/D155406
When entering fullscreen and saving the original position of a window,
also save the original position of its screen.
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
Daniel Holbert
Chris Peterson
Hiroyuki Ikezoe
Natalia Csoregi
sotaro
Andrew Osmond
Brad Werth
Cristian Tuns
Makoto Kato
Emilio Cobos Álvarez
Florian Quèze
Sandor Molnar
Olli Pettay
Butkovits Atila
Razvan Cojocaru
Ray Kraesig
Ryan VanderMeulen