After bug 1730284 we don't use it for throttling iframes, so the only
remaining use the test-only nsIDOMWindowUtils.paintCount. None of the
tests using it rely on the empty transaction case, so we should be able
to just remove this.
Differential Revision: https://phabricator.services.mozilla.com/D146589
After bug 1730284 we don't use it for throttling iframes, so the only
remaining use the test-only nsIDOMWindowUtils.paintCount. None of the
tests using it rely on the empty transaction case, so we should be able
to just remove this.
Differential Revision: https://phabricator.services.mozilla.com/D146589
Although not needed right now (checkerboarding backgrounds get
a slice anyway due to being a different scroll root), this will
be important for the upcoming work to make backdrop filter
roots implicit. This allows WR to know when slicing up a content
slice if the prim is relevant to the backdrop root.
Differential Revision: https://phabricator.services.mozilla.com/D146145
The scroll snap spec defines the concepts [1]. There are three type of scroll
operations. 1) intended end position, 2) intended direction and end position
and 3) intended direction.
Basically our existing ScrollUnits types correspond;
1) DEVICE_PIXELS, WHOLE => intended end position
2) PAGES => intended direction and end position
3) LINES => intended direction
There are two exceptions in the `intended direction and end position` case,
scrollBy() and fling gestures (on Linux). They were defined as scroll operations
with DEVICE_PIXELS unit, but the spec cleary says they are `intended direction
and end position` operations.
Note that we will also use this information for scroll-snap-stop property since
the properly will only have effects on both 2) and 3) cases.
[1] https://drafts.csswg.org/css-scroll-snap/#scroll-types
Depends on D145190
Differential Revision: https://phabricator.services.mozilla.com/D145191
The scroll snap spec defines the concepts [1]. There are three type of scroll
operations. 1) intended end position, 2) intended direction and end position
and 3) intended direction.
Basically our existing ScrollUnits types correspond;
1) DEVICE_PIXELS, WHOLE => intended end position
2) PAGES => intended direction and end position
3) LINES => intended direction
There are two exceptions in the `intended direction and end position` case,
scrollBy() and fling gestures (on Linux). They were defined as scroll operations
with DEVICE_PIXELS unit, but the spec cleary says they are `intended direction
and end position` operations.
Note that we will also use this information for scroll-snap-stop property since
the properly will only have effects on both 2) and 3) cases.
[1] https://drafts.csswg.org/css-scroll-snap/#scroll-types
Depends on D145190
Differential Revision: https://phabricator.services.mozilla.com/D145191
There are cases where we want to scroll across documents (like
scrollIntoView), and bailing out for those is incorrect. This
usually can't happen because in HTML documents we always have a root
scroll frame, but for fixed positioned elements it can happen, as those
are not parented to it.
This came up in https://github.com/w3c/csswg-drafts/issues/5492, and
fixes the only case where Firefox and Safari differ (C).
ScrollFrameRectIntoView knows how to deal with non-scroll-frames, and
takes care of jumping across documents if necessary, so passing the root
frame is fine. We only needed to walk out the parent chain to be able to
accumulate all our continuation bounds relative to the same frame.
In practice the bail out code should now be unreachable. Add an
assertion to that effect.
Tests for this are already upstream in WPT, and pass with this patch,
see:
* https://github.com/web-platform-tests/wpt/pull/33572
* https://github.com/web-platform-tests/wpt/pull/33633
Differential Revision: https://phabricator.services.mozilla.com/D143250
Also, remove unnecessary/implied "#ifdef" in code-comment alongside #endif a
few lines below, for consistency with the similar code-comment that I'm adding
in this patch.
Differential Revision: https://phabricator.services.mozilla.com/D143846
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
We only have to iterate over the open popups list (which is usually 0 or single digits) instead of every view.
Now that comboboxes definitely cannot create views, only xul menu popups can be floating popups.
Differential Revision: https://phabricator.services.mozilla.com/D138290
nsPresContest::RegisterManagedPostRefreshObserver still lets us add a managed post refresh observer until the mPresShell pointer on the prescontent is nulled out. That means that between the call to CancelManagedPostRefreshObservers and mPresContext->DetachPresShell() (which nulls out the mPresShell pointer on the prescontext) in PresShell::Destroy we can add a managed post refresh observer that will never get removed. Notably, destroying the frame tree happens between these two calls.
So move the CancelManagedPostRefreshObservers call to happen right after we null out the mPresShell pointer on the prescontext.
In bug 1737503 I want to add a managed post refresh observer when we destroy a subdocument frame (it's only interested in the recreate frames case not the destruction case, but not an easy way to tell them apart afaik), so it triggers this bug. The patch and test I have for that bug exercise this scenario.
Differential Revision: https://phabricator.services.mozilla.com/D135340
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
No behavior change (you can't have an in-process frame container and a
BrowserChild at the same time), but avoids some needless refcounting
overhead and makes it simpler to follow.
Differential Revision: https://phabricator.services.mozilla.com/D133770
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
It's an internal API corresponding to `Selection.getRangeAt` DOM API.
I think that it should use `uint32_t` rather than `size_t` because of the
consistency with the DOM API and `Selection::RangeCount()`.
This patch fixes all callers of `GetRangeAt()`, and rewrites it with ranged-
loops unless original ones do not refer `RangeCount()` every time and may run
script in the loop.
Differential Revision: https://phabricator.services.mozilla.com/D128848
Building with --disable-xul has been busted since _at least_ bug
1082579, for more than 7 years (I didn't try to track that down
further). It's time to recognize that the option serves no purpose.
Differential Revision: https://phabricator.services.mozilla.com/D133161
