Though this patch includes two wpt reftests, both are almost the same.
There are two differnces:
1) Explicitly set dom.meta-viewport.enabled=true and
layout.scroll_fixed_content_into_view_visually=true
2) The target element of scrollIntoView, a position:sticky element and a
position: fixed element
Thus the test in mozilla directory runs through the mobile specific code
path even on desktops.
Differential Revision: https://phabricator.services.mozilla.com/D286592
Though this patch includes two wpt reftests, both are basically
identical. The only one difference is the one in mozilla directory runs
with dom.meta-viewport.enabled=true so that the test runs through the
mobile specific code path even on desktops.
Differential Revision: https://phabricator.services.mozilla.com/D286592
For the example here, this reduces the jank when deleting the JS source
from 3.6 seconds to 650ms in my local build, because we are no longer
shifting all the entries of a large array each time we delete a frame
from the list.
Differential Revision: https://phabricator.services.mozilla.com/D270541
Now that we only have one scroll container class I think this can be
easier. Stash the pointer lazily in ScrollContainerFrame rather than a
frame property. Remove nsIScrollPositionListener, because it's only used
by StickyScrollContainer.
Differential Revision: https://phabricator.services.mozilla.com/D260629
... In addition to previous parameters, we need access to the positioned
frame, as well as the containing block's size (If we're in reflow).
Differential Revision: https://phabricator.services.mozilla.com/D249625
This reverts commit ec57e25d89.
Revert "Bug 1923961: Adjust WPT expectations. r=firefox-style-system-reviewers,emilio"
This reverts commit f2612695a7.
Revert "Bug 1923961: Resolve anchor() in calc(). r=firefox-style-system-reviewers,emilio"
This reverts commit b206c5264b.
Revert "Bug 1923961: Initial implementation of anchor lookup for anchor(). r=firefox-style-system-reviewers,emilio"
This reverts commit 56c17701c5.
Revert "Bug 1923961: Make `nsLayoutUtils::GetRectRelativeToFrame` take in const ptrs. r=firefox-style-system-reviewers,emilio"
This reverts commit 34fb773837.
Revert "Bug 1923961: Pass the new AnchorPosResolutionParams to servo side. r=firefox-style-system-reviewers,emilio"
This reverts commit 73477e3296.
Revert "Bug 1923961: Unify anchor resolution parameters and use it for inset resolution. r=layout-reviewers,emilio"
This reverts commit 8461579472.
Revert "Bug 1923961: Expose `AnchorSide` to C++. r=firefox-style-system-reviewers,boris"
This reverts commit 7ecbb38056.
... In addition to previous parameters, we need access to the positioned
frame, as well as the containing block's size (If we're in reflow).
Differential Revision: https://phabricator.services.mozilla.com/D249625
This reverts commit f94a0ccf5a.
Revert "Bug 1923961: Adjust WPT expectations. r=firefox-style-system-reviewers,emilio"
This reverts commit e3e24626a3.
Revert "Bug 1923961: Resolve anchor() in calc(). r=firefox-style-system-reviewers,emilio"
This reverts commit a21f60c569.
Revert "Bug 1923961: Initial implementation of anchor lookup for anchor(). r=firefox-style-system-reviewers,emilio"
This reverts commit daaa53a9ce.
Revert "Bug 1923961: Make `nsLayoutUtils::GetRectRelativeToFrame` take in const ptrs. r=firefox-style-system-reviewers,emilio"
This reverts commit c1db75e7fc.
Revert "Bug 1923961: Pass the new AnchorPosResolutionParams to servo side. r=firefox-style-system-reviewers,emilio"
This reverts commit e0f8f99c69.
Revert "Bug 1923961: Unify anchor resolution parameters and use it for inset resolution. r=layout-reviewers,emilio"
This reverts commit adc70f8493.
Revert "Bug 1923961: Expose `AnchorSide` to C++. r=firefox-style-system-reviewers,boris"
This reverts commit b917ffcec6.
... In addition to previous parameters, we need access to the positioned
frame, as well as the containing block's size (If we're in reflow).
Differential Revision: https://phabricator.services.mozilla.com/D249625
Don't have to write more one-off wrappers for size and margin.
It does cost having to copy fallback values, but that may
not be a huge tradeoff.
Differential Revision: https://phabricator.services.mozilla.com/D237097
Try to resolve math function nodes with percentage basis of zero. Invalid
anchor functions will make the value Invalid-At-Computed-Value-Time (i.e.
`auto`), so that is handled. Otherwise, `CalcNode` existing indicates use
of percentage values and/or anchor functions. If only anchor functions
are used, we can use the resolved value as-is - otherwise, it must be
re-resolved before its value is queried.
This is of course redundant, and may require some optimization down
the line (We don' eagerly get percentage basis since that requires
ancestor traversal that may be wasted).
Differential Revision: https://phabricator.services.mozilla.com/D237095
Don't have to write more one-off wrappers for size and margin.
It does cost having to copy fallback values, but that may
not be a huge tradeoff.
Differential Revision: https://phabricator.services.mozilla.com/D237097
Try to resolve math function nodes with percentage basis of zero. Invalid
anchor functions will make the value Invalid-At-Computed-Value-Time (i.e.
`auto`), so that is handled. Otherwise, `CalcNode` existing indicates use
of percentage values and/or anchor functions. If only anchor functions
are used, we can use the resolved value as-is - otherwise, it must be
re-resolved before its value is queried.
This is of course redundant, and may require some optimization down
the line (We don' eagerly get percentage basis since that requires
ancestor traversal that may be wasted).
Differential Revision: https://phabricator.services.mozilla.com/D237095
Don't have to write more one-off wrappers for size and margin.
It does cost having to copy fallback values, but that may
not be a huge tradeoff.
Differential Revision: https://phabricator.services.mozilla.com/D237097
Try to resolve math function nodes with percentage basis of zero. Invalid
anchor functions will make the value Invalid-At-Computed-Value-Time (i.e.
`auto`), so that is handled. Otherwise, `CalcNode` existing indicates use
of percentage values and/or anchor functions. If only anchor functions
are used, we can use the resolved value as-is - otherwise, it must be
re-resolved before its value is queried.
This is of course redundant, and may require some optimization down
the line (We don' eagerly get percentage basis since that requires
ancestor traversal that may be wasted).
Differential Revision: https://phabricator.services.mozilla.com/D237095
And kick a reflow for the sticky elements when the dynamic toolbar is hidden so that
the sticky elements' position laid out on the main-thread is properly updated there.
These stuffs are basically same as we've done for position:fixed elements.
Differential Revision: https://phabricator.services.mozilla.com/D223906
We rely on positioning ancestors before descendants to get the right
position. This was very implicitly enforced before the regressing bug,
by reframing on position changes (due to the order
StickyScrollContainer::AddFrame was called, ancestors before children).
In order to support dynamic sticky changes without reframing, we need to
handle the case of an existing ancestor switching position to sticky
dynamically.
Luckily we already have the right data-structure for that, so the change
is rather trivial.
Write a testharness test for this because APZ does get the position
right, so it's more future-proof against regressions to just test the
raw layout values.
Differential Revision: https://phabricator.services.mozilla.com/D216858
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
In block or flex layout, an 'auto' margin can be used to align the element by
consuming rest of the space of a particular side in its container [1]. However,
if we used the resolved 'auto' margin as part of the element's margin-box, it
won't stick within its scroll container if the margin is larger than the scroll
container's size in that dimension. Bug 1488080 comment 15 has more explanation.
The spec requires all 'auto' margin on the box are treated as zero when
computing Static-Position Rectangle [2] (See the requirement at the end of this
section).
[1] https://drafts.csswg.org/css-flexbox-1/#auto-margins
[2] https://drafts.csswg.org/css-position/#staticpos-rect
Differential Revision: https://phabricator.services.mozilla.com/D209097
Captions should be relatively-positioned (other browsers support this as
well). This ensures we correctly save their normal positions and thus
that the sticky scroll container knows how to reposition them correctly.
Avoid registering inner table frames with the sticky scroll container to
make the assertion sound in cases of sticky-positioned tables.
Differential Revision: https://phabricator.services.mozilla.com/D147092
Captions should be relatively-positioned (other browsers support this as
well). This ensures we correctly save their normal positions and thus
that the sticky scroll container knows how to reposition them correctly.
Avoid registering inner table frames with the sticky scroll container to
make the assertion sound in cases of sticky-positioned tables.
Differential Revision: https://phabricator.services.mozilla.com/D147092
Sylvestre Ledru