And remove one unused caller.
This might change behavior of some selection contrast checks and backplating
which will potentially use the right background-color after this patch. The
next patch ensures this is also accounted for for scrollbars.
Unfortunately selection contrast checks are non-trivial to test because we only
do the contrast check with system colors, and we'd need a default selection
color close to the highlight color to do this.
Differential Revision: https://phabricator.services.mozilla.com/D151017
That was about XBL constructors being able to run script. But XBL is
gone and this should just be wasted work.
I want to land this in preparation for container queries substantially
changing the model here.
Differential Revision: https://phabricator.services.mozilla.com/D151495
The existing frame label was reusing the function name, but we already
have it when using native stacks. Renaming it to a more understandable
name should make it easier for our javascript developers users without
impairing gecko developers.
Differential Revision: https://phabricator.services.mozilla.com/D150976
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
The current implementation of TimelineConsumers contains some unnecessary
complexity due to how it is initialized as a singleton, and the need for it to
be initialized and used in a threadsafe way. This patch attempts to simplify it
by making all members static, and removing the need to explicitly observe
shutdown for cleanup.
In addition, this approach avoids the risk of the type being accessed from
off-main-thread during initialization or shutdown.
Depends on D150442
Differential Revision: https://phabricator.services.mozilla.com/D150443
nsImageGeometryMixin is used to redraw images with sync decoding. Without it,
if we paint an image with non-sync decoding, we won't know that it will be
drawn differently with sync decoding and so don't have a mechanism to include
it in the invalid region.
Currently the main situation where we draw images with non-sync decoding and
then with sync decoding is during reftests. If we unconditionally use sync
decoding during reftests we don't have to worry about the situation where we
switch. This will let us resolve the problems associated with nsImageGeometryMixin.
Differential Revision: https://phabricator.services.mozilla.com/D149657
nsImageGeometryMixin is used to redraw images with sync decoding. Without it,
if we paint an image with non-sync decoding, we won't know that it will be
drawn differently with sync decoding and so don't have a mechanism to include
it in the invalid region.
Currently the main situation where we draw images with non-sync decoding and
then with sync decoding is during reftests. If we unconditionally use sync
decoding during reftests we don't have to worry about the situation where we
switch. This will let us resolve the problems associated with nsImageGeometryMixin.
Differential Revision: https://phabricator.services.mozilla.com/D149657
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
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
