Convert `nsIScrollableFrame` to `ScrollContainerFrame` for all the APIs in
nsLayoutUtils, and then adapt other callers until everything compiles.
In `nsLayoutUtils::CalculateBasicFrameMetrics()`'s documentation,
s/ComputeFrameMetrics/ComputeScrollMetadata/ because the method was renamed in
https://hg.mozilla.org/mozilla-central/rev/cb2023f50288
Differential Revision: https://phabricator.services.mozilla.com/D211493
Convert `nsIScrollableFrame` to `ScrollContainerFrame` for all the APIs in
nsLayoutUtils, and then adapt other callers until everything compiles.
In `nsLayoutUtils::CalculateBasicFrameMetrics()`'s documentation,
s/ComputeFrameMetrics/ComputeScrollMetadata/ because the method was renamed in
https://hg.mozilla.org/mozilla-central/rev/cb2023f50288
Differential Revision: https://phabricator.services.mozilla.com/D211493
We will need the snap area, (i.e. SnapTarget::mSnapArea) in SnapPosition to tell
whether the snap area is visible or not if we snap to a candidate snap position.
Though SnapPosition::mPosition is redundant, it's equivalent to either
SnapTarget::mSnapPoint.mX or SnapTarget::mSnapPoint.mY, if we omit it, we need
another variable representing the axis of SnapPosition.
Differential Revision: https://phabricator.services.mozilla.com/D184341
It's possible that multiple snap target elements are located at the same
position in one axis but at different position in the other axis. We need to
keep track of them respectively in each CandidateTracker.
Differential Revision: https://phabricator.services.mozilla.com/D184339
The assertion is valid, but fixing it would be a bit of work (bug 1798240),
so now we degrade the assertion to make it harmless on fuzzers works.
Differential Revision: https://phabricator.services.mozilla.com/D160742
If we return the snap target in such cases, even though the target position is
unchanged from the original scroll destination, the target will be handled as a
valid last-snapped target element, thus we will try to re-snap to the element's
scroll-snap-align position rather than keeping the scroll position as it is.
Differential Revision: https://phabricator.services.mozilla.com/D152353
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 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
The second best edge is used for `snap-overflow` feature [1]. The
`snap-overflow` is applied when the following conditions are met.
1) A scroll snap target element is larger than the snapport (e.g. scrollport)
in an axis
2) The distance between the best edge and the second best edge (on the opposite
side of the best edge) is later than the snapport size in the axis
There was a problem in our implementation. For example, in below diagram, D is
the original destination of the given scroll operation, 1 is the best edge, 2 is
the second best in our original implementation and 3 is of of the other snap
points. In this case if there's an element larger than the distance between 1
and 3 and if the snapport size is larger than the distance between 1 and 2 but
smaller than the distance between 1 and 3, we should apply `snap-overflow`.
2 1 D 3
|-|---|-----|
There are a couple of test cases in wpt for this condition, for example there's
one of them in oveflowing-snap-area.html [2]. That test case have been passed
incorrectly due to our incorrect `snap-scope` implementation which will be fixed
a subsequent change in this commit series.
[1] https://drafts.csswg.org/css-scroll-snap-1/#snap-overflow
[2] https://searchfox.org/mozilla-central/rev/13d69189a8abfc5064fe44944550b9b6eb4544f5/testing/web-platform/tests/css/css-scroll-snap/overflowing-snap-areas.html#131-137
Differential Revision: https://phabricator.services.mozilla.com/D144531
The issues fall into these categories:
- Files that used StaticPrefs::layout_XYZ() API or gfxVars::XYZ that needed an
include. (Addressed by adding the missing include.)
- Files that use mozilla::dom::XYZ or mozilla::gfx::XYZ without qualifying the
namespace & without a 'using' decl. (Addressed by adding "using".)
- A few other includes for types/inlines that were used without their header.
Depends on D50162
Differential Revision: https://phabricator.services.mozilla.com/D50163
Ting-Yu Lin