Only GeckoMVMContext really needs the flush, to measure scrolled height
afterwards. Do that explicitly.
This shouldn't change behavior, for the most part; there was a preload
test that relied on the flush when changing DPI to start a run really
clean, but other than that this looks green on try.
Should at best be neutral (just code clean-up), or be a performance
improvement.
In a follow-up, we can possibly remove the DelayedResize code from the
view manager, though I need to think how to possibly coalesce the MVM
reflows, so let's not do that yet.
Differential Revision: https://phabricator.services.mozilla.com/D155385
Only GeckoMVMContext really needs the flush, to measure scrolled height
afterwards. Do that explicitly.
This shouldn't change behavior, for the most part; there was a preload
test that relied on the flush when changing DPI to start a run really
clean, but other than that this looks green on try.
Should at best be neutral (just code clean-up), or be a performance
improvement.
In a follow-up, we can possibly remove the DelayedResize code from the
view manager, though I need to think how to possibly coalesce the MVM
reflows, so let's not do that yet.
Differential Revision: https://phabricator.services.mozilla.com/D155385
This still doesn't fire on print settings changes, so it uses the
default page size. Which is probably better than nothing, but...
To make viewport-size media-query listeners work more generally for
printed documents, we would need to re-clone the top document
unconditionally for all print settings changes, which needs front-end
work at least, and is dubious if the page changes dynamically.
Differential Revision: https://phabricator.services.mozilla.com/D150499
This is far from fully perfect (specially when dealing with nested
containers, we need to be smarter when updating there), but it's
incremental progress.
Differential Revision: https://phabricator.services.mozilla.com/D151496
This is far from fully perfect (specially when dealing with nested
containers, we need to be smarter when updating there), but it's
incremental progress.
Differential Revision: https://phabricator.services.mozilla.com/D151496
In order to support record the last user input for touch given APZ won't
synthesize mouse event for touch in parent process. Using pointer event could
support pen input nicely, too.
Differential Revision: https://phabricator.services.mozilla.com/D151282
In order to support record the last user input for touch given APZ won't
synthesize mouse event for touch in parent process. Using pointer event could
support pen input nicely, too.
Differential Revision: https://phabricator.services.mozilla.com/D151282
In order to support record the last user input for touch given APZ won't
synthesize mouse event for touch in parent process. Using pointer event could
support pen input nicely, too.
Differential Revision: https://phabricator.services.mozilla.com/D151282
The basic machinery to trigger re-snap is same as what scroll anchoring does,
queueing a triggering request and flush the queued requests after reflows
finished.
Depends on D148862
Differential Revision: https://phabricator.services.mozilla.com/D148863
Implements showing a "Paste" popup at the last mouse position (which
overlapped the browser window) when a certain custom event is received.
Creating and dispatchting that event is implemented in one of the
following parts.
Differential Revision: https://phabricator.services.mozilla.com/D135333
Add a dom/base/rust crate called just "dom" where we can share these.
Most of the changes are automatic:
s/mozilla::EventStates/mozilla::dom::ElementState/
s/EventStates/ElementState/
s/NS_EVENT_STATE_/ElementState::/
s/NS_DOCUMENT_STATE_/DocumentState::/
And so on. This requires a new cbindgen version to avoid ugly casts for
large shifts.
Differential Revision: https://phabricator.services.mozilla.com/D148537
If allocation fails, we'll now just discard the entire contents of
mAllocatedPointers and stop using it going forward.
See the documentation alongside the mAllocatedPointers declaration (in this
patch) for more details.
Differential Revision: https://phabricator.services.mozilla.com/D143416
This patch doesn't change behavior. As of this patch, this variable gets
instantiated immediately (in the PresShell constructor) and is never null, so
no logic/beheavior has changed.
This lays the groundwork for the next patch, which will add one case where this
variable does get nulled out (and add logic to handle that).
Differential Revision: https://phabricator.services.mozilla.com/D143411
The regular scroll position restoration code will restore it.
Specifically, in ScrollFrameHelper::SaveState
https://searchfox.org/mozilla-central/rev/44ae61c5eeb150cb77b6b8511ceee7ddd6892cb7/layout/generic/nsGfxScrollFrame.cpp#7376
we store the visual viewport offset. ScrollFrameHelper::ScrollToRestoredPosition will try to restore both the layout scroll offset and the visual viewport offset by calling ScrollToWithOrigin (which leads to ScrollToImpl) and PresShell::ScrollToVisual respectively.
I observed the following sequence of events when running gfx/layers/apz/test/mochitest/browser_test_background_tab_load_scroll.js in one of the cases that it fails for me locally.
-ScrollFrameHelper::NotifyApzTransaction is called after sending a transaction to webrender, this sets mAllowScrollOriginDowngrade = true.
-the scroll frame is destroyed and re-created (I'm not sure why this destroy and re-create happened, I didn't investigate), we call SaveState and RestoreState. So now mLastScrollOrigin == Other, and mAllowScrollOriginDowngrade == true.
-the test calls ScrollBy, so we get a call to ScrollToImpl with aOrigin == Relative
-aOrigin gets changed to Other here https://searchfox.org/mozilla-central/rev/9b0bdcc37419e6765223358a31a4a54d62e1cd97/layout/generic/nsGfxScrollFrame.cpp#2979
-the code just below that determines that it is not a downgrade, so we update mLastScrollOrigin to Other (not a change) and set mAllowScrollOriginDowngrade = false
-ScrollFrameHelper::NotifyApzTransaction is _not_ called (probably because we are in a background tab), so mAllowScrollOriginDowngrade remains false
-the scroll frame is now at position 20000 and the visual viewport offset (stored on the presshell) is also 20000.
-the scroll frame is destroyed and re-created (this one I investigated, it's because the font subsystem has finished loading and asks for a global reconstruct https://searchfox.org/mozilla-central/rev/9b0bdcc37419e6765223358a31a4a54d62e1cd97/layout/base/PresShell.cpp#9830), we call SaveState and RestoreState. So mLastScrollOrigin == Other, and mAllowScrollOriginDowngrade == true (the same values.
-we get a call to ScrollToRestoredPosition for the newly re-created scroll frame, we are trying to scroll from the current layout scroll position of 0 to the one we had before destruction and re-creation (20000). The visual viewport offset that is stored on the presshell has not been affected, it is still 20000.
-this gets to ScrollToImpl and with aOrigin == Restore
-we arrive at https://searchfox.org/mozilla-central/rev/9b0bdcc37419e6765223358a31a4a54d62e1cd97/layout/generic/nsGfxScrollFrame.cpp#3000 and Restore is a downgrade from Other, and mAllowScrollOriginDowngrade is false so we do not change mLastScrollOrigin (still Other) and mAllowScrollOriginDowngrade remains false
-we arrive at the code in ScrollToImpl that updates the visual viewport offset on the presshell https://searchfox.org/mozilla-central/rev/9b0bdcc37419e6765223358a31a4a54d62e1cd97/layout/generic/nsGfxScrollFrame.cpp#3232
-mLastScrollOrigin is Other, which can clobber apz, so we enter the if and add the difference between the before/after layout scroll position from this ScrollToImpl call (20000-0 = 20000) to the visual viewport offset (20000), getting 40000, which gets clamped to the max ~38000.
-and now the layout scroll position and the visual viewport offset have been detached when they shouldn't be.
If we reset the visual viewport offset when the scroll frame is destroyed we avoid the problem here.
Differential Revision: https://phabricator.services.mozilla.com/D139792
Extensions are using getComputedStyle(body).backgroundColor, which is
wrong at multiple levels.
The one that matters for this bug is that it is not color-scheme aware.
Depends on D133770
Differential Revision: https://phabricator.services.mozilla.com/D133771
I guess we need to do this every time we get a new APZC tree manager (because that is where the zoom constraints map/cache is stored). I'm not sure how to detect that or if there are other cases we haven't covered.
Differential Revision: https://phabricator.services.mozilla.com/D113608
We only need to clean up the frames for its flat tree children which are
about to go away from the flat tree, but we don't need to do anything
else. This avoids issues with the following patches because menupopups
depend a lot on their frame tree state.
Differential Revision: https://phabricator.services.mozilla.com/D131083
Otherwise if we get an event targeting a different suppressed pres shell
while we're unsuppressing we might get stuck delaying the event over and
over, see the links in comment 33.
Not sure how to get a repro for this, the patch is written based on the
pernosco session, but suggestions welcome.
Differential Revision: https://phabricator.services.mozilla.com/D130100
