And apply the auto-fix from the linter. Note that we exclude RefPtr from
the check as it plays badly with our CanRunScriptChecker's linter.
We also explicitly silent warning for loops on nsTObserverArray, as their
iterator is designed to support invalidation.
Differential Revision: https://phabricator.services.mozilla.com/D293497
Per spec, snap positions only affect the nearest ancestor scroll
container, so re-snapping is normally only triggered on that container.
However, if a snap target contains the focused element, ancestor scroll
containers of that snap target may also need to re-snap.
Differential Revision: https://phabricator.services.mozilla.com/D296592
Add a new WPT (prefer-element-having-focused-element.html) since no
existing test covered this case. It verifies that a snap target
containing a focused non-snap element takes priority over other
aligned snap targets.
Differential Revision: https://phabricator.services.mozilla.com/D296591
Per https://drafts.csswg.org/css-scroll-snap-1/#multiple-aligned-snap-areas
step 4.3: for each box in the candidate set, remove any box that is an
ancestor of that box. This ensures the innermost (most-descendant) snap
target is preferred over its ancestors during resnap.
Uses nsContentUtils::ContentIsFlattenedTreeDescendantOf to check ancestry
in the flat tree, which matches how CSS layout traverses the element tree.
Differential Revision: https://phabricator.services.mozilla.com/D296585
This uses the existing operator<< overload for nsTArray, which in turn
makes use of the overload for SnapTarget or SnapTarget* as needed.
Differential Revision: https://phabricator.services.mozilla.com/D298649
This localizes the conversion from UTF-16 into the helper for
a single snap target.
Note that NS_LossyConvertUTF16toASCII derives from nsAutoCString
and adds no state, so it's safe to slice to nsAutoCString.
Differential Revision: https://phabricator.services.mozilla.com/D298646
When re-snapping after a layout change, we build separate candidate sets
for the inline (X) and block (Y) axes from the previously snapped targets,
using mIdsOnX and mIdsOnY respectively.
This implements step 5 of spec section 6.2.1: if the inline and block sets
are overlapping, both are replaced with their intersection. If the sets are
disjoint, the block-axis set takes precedence and determines the snap
position for both axes.
Differential Revision: https://phabricator.services.mozilla.com/D285438
Mousewheel scrolls on a axis of a scroll container with a scroll-snap-type of
proximity should have the scroll target of the intended destination
instead of the scroll start if no snap target is found.
Differential Revision: https://phabricator.services.mozilla.com/D270173
In Gecko scroll snap id is a raw pointer of each snap target element. So
if the snap target element is larger than the snapport and once after
we snapped to a point inside element but the point is away from the
element's `scroll-snap-align` point, the snap id forces us to snap to
the element's `scroll-snap-align` point when we try to re-snap.
Differential Revision: https://phabricator.services.mozilla.com/D258498
Since bug 1922904, GetSnapPointForDestination had returned an ineligible
snap point.
For exmaple, given that there's a scroll container only wants to snap
horizontally and there are 3 snap target points, (0, 0), (100, 0) and
(200,0). Then if the user tries to scroll vertically to (0, 100), the
function returned (0, 0) as a valid snap position for the vertical scroll
operation. With this change the function now returns (0, 100) so that
the user can scroll vertically to the correct position.
Differential Revision: https://phabricator.services.mozilla.com/D231058
Since bug 1922904, GetSnapPointForDestination had returned an ineligible
snap point.
For exmaple, given that there's a scroll container only wants to snap
horizontally and there are 3 snap target points, (0, 0), (100, 0) and
(200,0). Then if the user tries to scroll vertically to (0, 100), the
function returned (0, 0) as a valid snap position for the vertical scroll
operation. With this change the function now returns (0, 100) so that
the user can scroll vertically to the correct position.
Differential Revision: https://phabricator.services.mozilla.com/D231058
Since bug 1922904, GetSnapPointForDestination had returned an ineligible
snap point.
For exmaple, given that there's a scroll container only wants to snap
horizontally and there are 3 snap target points, (0, 0), (100, 0) and
(200,0). Then if the user tries to scroll vertically to (0, 100), the
function returned (0, 0) as a valid snap position for the vertical scroll
operation. With this change the function now returns (0, 100) so that
the user can scroll vertically to the correct position.
Differential Revision: https://phabricator.services.mozilla.com/D231058
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
Hiroyuki Ikezoe