Automatic update from web-platform-tests
[FlexNG] Use fragment order as source of truth within simplified layout
Step 3/4 in getting flex to use the simplified layout pass.
We need to use the fragment order as the source or truth as we use the
fragment order as the correct paint order.
The downside of this approach is that we now iterate twice over the
children, once for the fragments, and again for the nodes.
Adding placeholder fragments for the static-positions for the OOF
will fix this.
Bug: 845235
Change-Id: Idb149a25975885cee389c3bae1dd9021dbb5a467
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2187854
Commit-Queue: Koji Ishii <kojii@chromium.org>
Reviewed-by: Koji Ishii <kojii@chromium.org>
Cr-Commit-Position: refs/heads/master@{#767208}
--
wpt-commits: 9bbbd9e569e4e5533af0ce55ed4b699b715f7ec6
wpt-pr: 23496
Automatic update from web-platform-tests
[FlexNG] Make simplified layout algorithm use static-position from layer
Step 2/4 in getting flex to use the simplified layout pass.
Instead of re-calculating the static-position within the simplified
layout pass, store this on the paint-layer, and read it back during
the simplified pass.
This isn't ideal. A better way of doing this would be to add
"placeholder" fragments which contain this information instead.
Bug: 845235
Change-Id: I1e8af7f2c487f22c72d657eb1a20b3022329899e
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2185513
Commit-Queue: Koji Ishii <kojii@chromium.org>
Reviewed-by: Koji Ishii <kojii@chromium.org>
Cr-Commit-Position: refs/heads/master@{#767206}
--
wpt-commits: c313d1fe582d0361f3c2165799e0e4ded109f327
wpt-pr: 23497
Automatic update from web-platform-tests
Add more references to sticky position ref tests
This is a follow-up patch of
https://chromium-review.googlesource.com/c/chromium/src/+/2105754
This patch adds more reference rectangles to sticky ref-tests to catch
when the main thread position is different from the sticky position.
Bug: 1059272
Change-Id: Ib3101e58a95db134a427b2852bca4c4bd58f805e
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2137828
Reviewed-by: Robert Flack <flackr@chromium.org>
Commit-Queue: Hao Sheng <haozhes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#761027}
--
wpt-commits: 9586cd0785957c1f58c58cc9df9bc7410ffe8aff
wpt-pr: 22752
Automatic update from web-platform-tests
Add more references to sticky position ref tests
This is a follow-up patch of
https://chromium-review.googlesource.com/c/chromium/src/+/2105754
This patch adds more reference rectangles to sticky ref-tests to catch
when the main thread position is different from the sticky position.
Bug: 1059272
Change-Id: Ib3101e58a95db134a427b2852bca4c4bd58f805e
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2137828
Reviewed-by: Robert Flack <flackr@chromium.org>
Commit-Queue: Hao Sheng <haozhes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#761027}
--
wpt-commits: 9586cd0785957c1f58c58cc9df9bc7410ffe8aff
wpt-pr: 22752
Automatic update from web-platform-tests
Verify layout position of sticky position elements in ref tests
Verify sticky position while composition happens. Catch when the main
thread position is different from the sticky position of ref tests.
Bug: 1059272
Change-Id: I3ec4fa391b42ff3783b2e89347a4bd10ab81faaf
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2105754
Commit-Queue: Hao Sheng <haozhes@chromium.org>
Reviewed-by: Kevin Ellis <kevers@chromium.org>
Reviewed-by: Robert Flack <flackr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#755248}
--
wpt-commits: 211c4a997d7622b034a82ef9b2772401c5fe771f
wpt-pr: 22312
Automatic update from web-platform-tests
Fix position:sticky when inside fixed subtree
In https://crrev.com/4d25b125dae5 I changed the scroll tree parenting
logic so that elements in position:fixed subtrees have the LayoutView's
ScrollNode as the scroll parent. This made sense since scrolling over a
fixed element should cause the document to scroll. However, this is
slightly different from how the transform tree looks. Because scrolling
the document doesn't cause position:fixed eement so translate, these
nodes don't have the LayoutView's ScrollTranslation transform node as an
ancestor.
As a simple example, a scrolling document with a position:fixed <div>
scroller will generate the following scroll and transform trees
(approximately):
*ScrollTree* *TransformTree*
Root Root
| |
VisualViewport Translation VisualViewport
| / \
LayoutView Translation / \
| Fixed LayoutView
Fixed Scroller Translation
The situation above makes sense for what parent-child relationships mean
in each tree: the scroll tree encodes how scrolls chain; scrolling on a
child should bubble up to its parent in this tree. The transform tree
encodes the physical effect of scrolling a node. In the above example,
scrolling from the fixed scroller should bubble up to the LayoutView
(when the scroller is fully scrolled) but scrolling the LayoutView will
not cause movement of the fixed scroller.
The above makes sense but caused sticky code to get confused. A sticky
constraint is attached to the scroll translation node. With the above
situation, this meant that inside a fixed subtree, we'd attach it to the
VisualViewport's scroll translation node. This was unexpected; the
constraints are in "document coordinates", meaning that to translate
them into the viewport space we must apply the scroll offset [1]. The
compositor would use the visual viewport's (typically 0) scroll offset
to adjust these values, leading to incorrect calculations.
This previously worked because the scroll node used in a fixed subtree
would be the visual viewport (before the CL mentioned at the top). In
[2] we check whether the current overflow clip is also our scroller,
prior to the CL this check have failed because "our scroller" was the
visual viewport but our clip was the LayoutView. Now they are both the
LayoutView.
The fix in this CL is to make the check in [2] more stringent; we also
want to make sure that our scroller is the nearest scroller in the
transform tree. That is, if we scroll it, will we cause the current node
to move? If not, we don't need a sticky constraint on the compositor
because user scrolling can't change the sticky's offset relative to its
clip.
[1] https://cs.chromium.org/chromium/src/cc/trees/property_tree.cc?l=321&rcl=628f869d1fda631a85f051ad13b5d278319298fc
[2] https://cs.chromium.org/chromium/src/third_party/blink/renderer/core/paint/paint_property_tree_builder.cc?l=553&rcl=99a5a1266f303ba6ae46174a2b4cbd165ea7e934
Bug: 1019142
Change-Id: I781943ff43514905d399803c780c6081d7d47e8f
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2097542
Reviewed-by: Robert Flack <flackr@chromium.org>
Commit-Queue: David Bokan <bokan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#750264}
--
wpt-commits: 1e6645ce41bc902a4c60d6f90a934f9d6d8a258a
wpt-pr: 22195
Automatic update from web-platform-tests
Don't let a CompositingInputsRoot be a contain:strict element if it was dirty.
contain:strict elements are stopping points for ancestor recursion when
finding a CompositingInputsRoot, but this should only be for when
*descendants* of the contain:strict element are dirtied, not the
contain:strict element itself.
This problem exhibited in a bug in a case when the contain:strict
element was also position:sticky, causing it to fail to update sticky
position constraints as a result.
Bug: 1051455
Change-Id: If7e9f3d19ce5dc949ee9ba6ab7c0c0c2e03b2f20
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2076546
Reviewed-by: Manuel Rego <rego@igalia.com>
Commit-Queue: Chris Harrelson <chrishtr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#745093}
--
wpt-commits: 859d8a4995e90ac5820ea4ae123aea72996c1a57
wpt-pr: 22000
Automatic update from web-platform-tests
[TableNG] Fix table's box sizing in UA stylesheet
Table width is treated as border-box width, but UA does not specify box-sizing,
so it defaults to content-box. This fixes it.
The fix required rebaseline of several tests.
The only "not clearly better" difference is %ge resolution block
size for captions. Old code resolved against table's border-box size,
new code resolves against content-box size.
FF/Edge/Legacy all disagree on what is the correct answer.
Filed a spec issue, hope to match FF.
https://github.com/w3c/csswg-drafts/issues/4676
Rebaseline details:
Better, passing more tests.
.../tables/table-ua-stylesheet-expected.txt | 2 +-
Test depended on table's default box-sizing being content-box. Made
table's box sizing explicit for the test.
.../web_tests/fast/borders/border-image-fill-no-border.html | 3 +
Better. Was testing old bad behavior. Fixed up test also passes in FF.
.../fast/table/min-width-html-block-table-expected.txt | 120 ++++++++++++++--------------
.../fast/table/min-width-html-inline-table-expected.txt | 120 ++++++++++++++--------------
.../web_tests/fast/table/script-tests/min-width-helpers.js | 30 +++----
Better. Table's absolute position was incorrect. Correct now.
.../platform/linux/tables/mozilla/bugs/bug145572-expected.png | Bin 4239 -> 4238 bytes
Not better, just different. Different sizes are used to resolve caption
percentage heights.
.../mozilla_expected_failures/bugs/bug3166-14-expected.png | Bin 4477 -> 4477 bytes
.../mozilla_expected_failures/bugs/bug3166-17-expected.png | Bin 4446 -> 4444 bytes
Bug: 423997
Change-Id: I8e090390970a637713a9e1d4b62dc55114fd944b
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2003810
Reviewed-by: Ian Kilpatrick <ikilpatrick@chromium.org>
Reviewed-by: David Grogan <dgrogan@chromium.org>
Commit-Queue: Aleks Totic <atotic@chromium.org>
Cr-Commit-Position: refs/heads/master@{#733115}
--
wpt-commits: e671d58951e69df89c05fb3eb2a361be3303aa38
wpt-pr: 21225
This change effectively disallows sticky elements to enlarge overflow
area. That is, the position of a sticky element will be bounded by the
union of scrolled frame's border-box and the overflow area created by
other non-sticky elements within the same block formatting context.
This makes Firefox's position:sticky elements behaves like Google Chrome
in this respect.
Differential Revision: https://phabricator.services.mozilla.com/D54345
--HG--
extra : moz-landing-system : lando
This change effectively disallows sticky elements to enlarge overflow
area. That is, the position of a sticky element will be bounded by the
union of scrolled frame's border-box and the overflow area created by
other non-sticky elements within the same block formatting context.
This makes Firefox's position:sticky elements behaves like Google Chrome
in this respect.
Differential Revision: https://phabricator.services.mozilla.com/D54345
--HG--
extra : moz-landing-system : lando
Automatic update from web-platform-tests
[FlexNG] Add support for OOF-positioned static-positions within FlexNG.
This builds on previous changes to (finally!) add the correct
static-positions within the NGFlexLayoutAlgorithm.
This takes into account the main-axis, and cross-axis
alignment/justification - and converts it to the correct
inline/block axis.
As we may not know the final block-size when we encounter an
OOF-positioned node, we "adjust" this within the fragment builder once
known.
This is important for block-end/block-center aligned OOF-positioned
nodes.
Bug: 845235
Change-Id: I45c89ae1f676ec06d742b86e4b744cfc3dbe6f75
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1841245
Commit-Queue: Ian Kilpatrick <ikilpatrick@chromium.org>
Reviewed-by: Morten Stenshorne <mstensho@chromium.org>
Reviewed-by: David Grogan <dgrogan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#723411}
--
wpt-commits: d38cc357aae049b305f136d0f0f20e1058008442
wpt-pr: 20642
Automatic update from web-platform-tests
Fix invalidation for OOF-positioned objects with a display change.
Previously this branch was too limiting. It was possible for both:
- Parent() == ContainingBlock() and,
- OriginalDisplay() == EDisplay::kInline or something else.
This means that we invalidate, and correctly re-calculate the new
static-position.
Change-Id: I045d7cc27c951b3ae0faa5dd14887852b38bc828
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1956373
Commit-Queue: Morten Stenshorne <mstensho@chromium.org>
Reviewed-by: Morten Stenshorne <mstensho@chromium.org>
Cr-Commit-Position: refs/heads/master@{#722798}
--
wpt-commits: e6b40ab46b6bea2dd79bf7365f12c7b0edd5ddf5
wpt-pr: 20667
Automatic update from web-platform-tests
[LayoutNGFragmentPaint] Fix containing-block of OOF-positioned objects.
We had an issue in the existing invalidation code when an object could
contain an OOF-positioned node, but wasn't a LayoutBlock.
This already happens when we have a LayoutInline being a
containing-block, but there are other cases where this is true.
Clusterfuzz found that LayoutTableSection falls into this category.
E.g.
The OOF-positioned node would be inserted into the nearest
containing-block (the anonymous LayoutTable in this case).
When it stopped being a containing-block, the OOF-positioned node was
never removed from the LayoutTable.
This caused a crash when the OOF's layout was invalidated.
The OOF marked itself, and the LayoutView (its new containing block)
for layout.
But the LayoutView didn't know it had this as an OOF-positioned child.
This patch moves the current logic within LayoutBlock into
LayoutBoxModelObject.
Bug: 1021491, 1021676, 1022545
Change-Id: I0f0b4c8aa655fc7edca5d79379205a8d445713d5
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1906708
Reviewed-by: Aleks Totic <atotic@chromium.org>
Reviewed-by: Morten Stenshorne <mstensho@chromium.org>
Reviewed-by: Koji Ishii <kojii@chromium.org>
Commit-Queue: Ian Kilpatrick <ikilpatrick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#714487}
--
wpt-commits: 491cd874e7bb2487829f83df8b25b2b70b4c5e22
wpt-pr: 20185
Automatic update from web-platform-tests
[LayoutNG] Disable first-tier OOF-cache when borders/scrollbars are present.
The first-tier OOF-cache attempts to skip all the OOF sizing and positioning
work required, as the other cache simply compares the constraint spaces
which can be (relatively) expensive to determine.
This first-tier cache works by comparing the available-size given to the
OOF-positioned descendant. If equal we can skip the OOF-positioned sizing
and positioning steps.
This mostly worked, however had an issue where the containing-block may have
added/removed a borders/scrollbars, but the available-size given remained
the same.
This resulted in an incorrectly positioned OOF-positioned node.
This fix disallows the first-tier cache when borders/scrollbars are present.
This is sufficiently rare that this cache still has a relatively high
hit-rate and is still relative cheap to calculate.
Bug: 1013866
Change-Id: I71d41d2c4b47bcff6412f395db2deabf2f6f3a8f
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1891768
Commit-Queue: Ian Kilpatrick <ikilpatrick@chromium.org>
Reviewed-by: Aleks Totic <atotic@chromium.org>
Reviewed-by: Morten Stenshorne <mstensho@chromium.org>
Cr-Commit-Position: refs/heads/master@{#714394}
--
wpt-commits: 87f0b7482549a035c7bd682f506f6bd88f569b60
wpt-pr: 20021
Automatic update from web-platform-tests
[LayoutNG] ComputeReplacedSize edge case fix
Edge case for "have aspect ratio, but no intrinsic size"
If there was no intrinsic size, we treated it as no size at all.
But, if there is a css size, we should use that instead.
Bug: 1015311
Change-Id: Ia8f12bd23cda5c18b9aae318eee91906840475d3
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1877595
Commit-Queue: Aleks Totic <atotic@chromium.org>
Reviewed-by: Ian Kilpatrick <ikilpatrick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#709134}
--
wpt-commits: cfffd794f8c086ac20c664658738a4dce18462c1
wpt-pr: 19857
Differential Revision: https://phabricator.services.mozilla.com/D53456
Automatic update from web-platform-tests
Translate the scroll coordinate to ScrollOrigin
Currently, the value of ScrollLeft / ScrollTop / ScrollTo for a box in
Element is the offset to the origin of ScrollableArea(left-top corner).
This behavior isn't consistent with Document-scroll or the behavior of
other vendors either whose origin is ScrollOrigin. There're compatibility
problems when the box has leftward or upwards scroll overflow direction.
According to the Specification, the scroll x-coordinate of a leftward box
is nonpositive, and the scroll y-coordinate of an upwards box is also
nonpositive. With using the origin of ScrollableArea, the coordinate
is always nonnegative.
In order to fix it, this patch transforms the scroll coordinate of a
box in Element interface to use ScrollOrigin as its origin.
There are a few cases needed to recalculate the scroll coordinate to
meet this change. Since the origin of scroll coordinate transforms
from the ScrollableArea origin to ScrollOrigin(), current_coordinate
is equal to old_coordinate - ScrollOrigin. E.g.
current_scrollLeft = old_scrollLeft - ScrollOrigin().X().
This behavior is guarded by a feature flag.
See intent to ship blink-dev thread:
https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/7X2CKPGeEa0
Bug: 721759
Change-Id: I0ceed62e6845c6e5cd976e59b36f292d60bb669c
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1700001
Reviewed-by: Jochen Eisinger <jochen@chromium.org>
Reviewed-by: David Bokan <bokan@chromium.org>
Reviewed-by: Frédéric Wang <fwang@igalia.com>
Commit-Queue: cathie chen <cathiechen@igalia.com>
Cr-Commit-Position: refs/heads/master@{#704470}
--
wpt-commits: 3001893957895fe522dee392b50deb6fde64d7d0
wpt-pr: 17851
Automatic update from web-platform-tests
[LayoutNG] Fix clusterfuzz crash
Using empty Optional<MinMax> to indicate that MinMax value
should not matter caused trouble with ng_length_utils
ResolveInlineLengthInternal, when max-width was fit-content.
Use MinMax(0, LayoutUnitMax) to indicate intrinsic size does
not matter instead. It accomplishes the same goal, computed
size does not get clamped by intrinsic.
I've also tested running it with width:max-content out of
fear that we might end up with too wide OOF, but that did
not happen.
Bug: 1010798
Change-Id: Ife11b3d9637be91cc0648b7f8485af51f07108bb
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1837118
Commit-Queue: Aleks Totic <atotic@chromium.org>
Auto-Submit: Aleks Totic <atotic@chromium.org>
Reviewed-by: Morten Stenshorne <mstensho@chromium.org>
Cr-Commit-Position: refs/heads/master@{#702525}
--
wpt-commits: baf914481d76b25d7d054a23564d5b5418dd9f8b
wpt-pr: 19487
Automatic update from web-platform-tests
[LayoutNG] Fix replaced abspos with no intrinsic size
One more abspos edge case:
Replaced element, with no intrinsic size, but with
intrinsic aspect ratio.
The example problem here is an SVG with aspect ratio,
but no intinsic size. According to the spec, its
inline size should fill container, and block size
should be derived from inline size and aspect ratio.
Existing code did not handle this case. If element
had no size, its size would be computed and get clamped
by minmax.
A replaced element with no size gets a default minmax of
300x150, so elements would effectively get clamped to minmax.
My fix is a bit of a hack. It uses absence of minmax as a signal
that size should not be clamped.
The intrinsic size handling is surprisingly complex for replaced
elements. I wonder if there are any other parts of NG that
need a close look in how replaced with aspect ratio/no size
are handled.
FF handles this correctly. Legacy does not.
Bug: 1003545
Change-Id: I1510611ff84a99a26bcade74cace2855e022f997
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1830326
Commit-Queue: Aleks Totic <atotic@chromium.org>
Reviewed-by: Morten Stenshorne <mstensho@chromium.org>
Reviewed-by: Ian Kilpatrick <ikilpatrick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#702150}
--
wpt-commits: 2f0b747361dc9b66b7dfc9e28d91fd84f346dd49
wpt-pr: 19383
Automatic update from web-platform-tests
[LayoutNG] Fix abspos replaced size with margins
NG was computing inline_size of replaced elements
with no intrinsic size (only aspect ratio) incorrectly.
Element's margin was not considered.
The fixes are:
- update code to use margin when computing inline_size
- update wpt exaustive replaced size test to include margins
- remove many stale expectations for position-absolute-replaced-minmax.html
With the updated test, Legacy still fails single test. I might
have to update expectations.
Bug: 1002748
Change-Id: I98b8595ce0e4dc0d19d1d8020e33fe17e125d41d
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1799422
Commit-Queue: Aleks Totic <atotic@chromium.org>
Reviewed-by: Ian Kilpatrick <ikilpatrick@chromium.org>
Reviewed-by: Morten Stenshorne <mstensho@chromium.org>
Reviewed-by: Christian Biesinger <cbiesinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#696101}
--
wpt-commits: dbf3183cf1e15b216c94aac238268efd84df57ca
wpt-pr: 19011
Automatic update from web-platform-tests
[LayoutNG] Simplified layout needs to account for table-cell intrinsic padding.
Previously we didn't account for intrinsic-padding when determining the
static postiion in the simplified layout algorithm.
When using vertical-align: middle (or something which triggers intrinsic
padding) a OOF-position node might "jump".
This was found with the lastpass password manager.
Bug: 1000864
Change-Id: I94831f735a7e0992130ae065b0f6c9c6abb8c37a
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1785898
Reviewed-by: Christian Biesinger <cbiesinger@chromium.org>
Reviewed-by: Aleks Totic <atotic@chromium.org>
Commit-Queue: Ian Kilpatrick <ikilpatrick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#693446}
--
wpt-commits: a6e7e60c55a11c1f12eeaa8384882fb3f70c127d
wpt-pr: 18859
Automatic update from web-platform-tests
Port a small collection of basic interpolation tests to WPT
These are mostly unrelated properties, but are also simple test cases.
Bug: 900581
Change-Id: I2353dbcb6ee733f9c0a9289b46eae4e00ade7c98
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1771576
Reviewed-by: Xida Chen <xidachen@chromium.org>
Commit-Queue: Stephen McGruer <smcgruer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#690597}
--
wpt-commits: 86e33a2375adc1d8c4249b01e92c4af3fc175b9b
wpt-pr: 18675
Automatic update from web-platform-tests
[LayoutNG] Consider nodes with only floats/OOFs as block-level.
Legacy/WebKit have a "interesting" behaviour for empty-inlines in that
they determine the static position of any (inline-level) OOF-positioned
nodes as if they were in the block-level context.
Other browsers do the following (testcase):
https://www.software.hixie.ch/utilities/js/live-dom-viewer/?saved=7055
FF - all inline-level
Safari/Legacy - all block-level
Edge - block-level for default/block-level
NG (prior to this change) - inline-level for default/inline-level.
This change makes the "default" e.g. a node with just floats/OOFs as
block-level to pick up this static position behaviour.
This matches the EdgeHTML behaviour.
Bug: 980908
Change-Id: Ifb92bf7e34ada669fa16a1ee5f9e9edaf4546768
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1696345
Commit-Queue: Ian Kilpatrick <ikilpatrick@chromium.org>
Commit-Queue: Emil A Eklund <eae@chromium.org>
Reviewed-by: Emil A Eklund <eae@chromium.org>
Cr-Commit-Position: refs/heads/master@{#677105}
--
wpt-commits: 7d2e6ae20d62092517732c76fd8588975b95744e
wpt-pr: 17808
Automatic update from web-platform-tests
[cssom] getComputedStyle not getComputedValue (#17799)
Fix typo in test titles.
--
wpt-commits: 9daa6ffd6eb28afb0940b7ac304b08e8383fc527
wpt-pr: 17799
Automatic update from web-platform-tests
[LayoutNG] Consider inline-level OOF-positioned nodes as "adjoining".
"adjoining" objects are used to indicate that a particular node might
need relayout once its BFC block-offset is resolved. Previously we
thought that we just needed to know about "adjoining-floats".
However inline-level OOF-positioned nodes also needs to know its BFC
block-offset as the static-position of these nodes depend on where
floats are.
Previously as we didn't know that we needed to relayout these nodes
we'd get the incorrect static-position. Now these nodes get the
correct static-position.
Bug: 982403, 980908
Change-Id: I89f18298fd7379358a681b98514891d8d35bc38e
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1692627
Reviewed-by: Emil A Eklund <eae@chromium.org>
Reviewed-by: Koji Ishii <kojii@chromium.org>
Commit-Queue: Ian Kilpatrick <ikilpatrick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#676263}
--
wpt-commits: 4f954c15e1dc8cf94f7a2231f648fb640509d9d4
wpt-pr: 17782
Automatic update from web-platform-tests
Don't consider fieldsets as replaced content.
They should be treated as regular block containers, as far as sizing is
concerned. The LayoutNG out-of-flow positioning machinery treated
fieldsets as replaced (since it was told to), and ended up with an
incorrect inline-size.
A "side-effect" of this fix is that now that fieldsets are no longer
treated as replaced content, they can can also fragment inside multicol
containers or paged media - just like any other block-level container.
This is good. There should be no reason to prohibit fragmentainer
breaks inside fieldsets. Added a test for it, to assert the new
behavior.
Bug: 979523
Change-Id: I2fd73f8324d3207c5d12c500b5632f631468ab34
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1685096
Reviewed-by: Ian Kilpatrick <ikilpatrick@chromium.org>
Reviewed-by: Koji Ishii <kojii@chromium.org>
Commit-Queue: Morten Stenshorne <mstensho@chromium.org>
Cr-Commit-Position: refs/heads/master@{#674096}
--
wpt-commits: 727763fa27f9d8d36c1c337dc2ac52ac092c61f0
wpt-pr: 17602
Automatic update from web-platform-tests
[LayoutNG] Fix for incorrect Legacy containing block oof removal
When containing block changes from being an OOF container
to not being one, it needs to remove the positioned descendants
from its list of positioned objects.
If an OOF object remains in the positioned objects list,
it will cause NGOutOfLayoutPart::SweepLegacyDescendants
to go into an infinite loop and run out of memory. This
was fixed to just trigger a DCHECK in a recent CL.
LayoutInline::StyleDidChange did not perform OOF descendant
removal correctly. LayoutInline OOF descendants are stored in
first non-anonymous block on parent chain, (container's container)
which is not the same as ContainingBlock().
Added a method that computes container's container to
LayoutObject, and made LayoutInline call it.
This fix also works for fixed, because
fixed containers are always absolute containers.
Bug: 977930
Change-Id: I9f88fe676ec67d9d6751f3502507d773ed978dc8
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1680123
Commit-Queue: Aleks Totic <atotic@chromium.org>
Reviewed-by: Ian Kilpatrick <ikilpatrick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#673156}
--
wpt-commits: a8405825541d608fd26f28b0af36e6b5c42fd70a
wpt-pr: 17542
Automatic update from web-platform-tests
[LayoutNG] Don't run the OOFLayoutPart if we have any adjoining floats.
If we have adjoining floats we'll revisit the node to correctly place
floats. During the first pass we may not have floats present within
lineboxes, causing NGContainerFragmentBuilder::GetChildOffset to fail.
This makes sure we don't run the OOFLayoutPart for this condition.
There is a followup cleanup patch I'll send out for review later which
speculatively places floats avoiding this condition also:
https://chromium-review.googlesource.com/c/chromium/src/+/1619047
Bug: 976397
Change-Id: I10db8207357572521fc9103134cb6fbf885c4a94
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1676727
Commit-Queue: Morten Stenshorne <mstensho@chromium.org>
Reviewed-by: Morten Stenshorne <mstensho@chromium.org>
Reviewed-by: Koji Ishii <kojii@chromium.org>
Cr-Commit-Position: refs/heads/master@{#672423}
--
wpt-commits: 5a42c001e74045dd9347ce9870fb7a8f17e6286a
wpt-pr: 17504
Automatic update from web-platform-tests
[LayoutNG] Fix DCHECK(NeedsLayout) for inline oof fixed container.
NGOutOfFlowLayoutDescendant.inline_container was not being set
correctly for an Element if:
- There is an OOF containing block between Element and
its Container(). This can only happens if Element is
position:fixed.
This caused Element not to be laid out after it got dirty (but
its containing block did not).
The fix is to set inline_container when Element's
NGOutOfFlowDesecendantCandidate gets propagated up the OOF
containing block chain.
For a while, I was afraid that this fundamentally broke
the concept of inline_container. I could not come up
with a counterexample that broke this fix.
Bug: 974760
Change-Id: Id16a0057f0aefe183c30c53244dd5c46108f093c
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1666809
Commit-Queue: Aleks Totic <atotic@chromium.org>
Reviewed-by: Emil A Eklund <eae@chromium.org>
Reviewed-by: Koji Ishii <kojii@chromium.org>
Cr-Commit-Position: refs/heads/master@{#670634}
--
wpt-commits: b6343fc17a3035a0c2170f44fb63df2356aa2cb9
wpt-pr: 17390
Automatic update from web-platform-tests
[LayoutNG] the real youtube button fix
Previous fix worked by eliminating cacheing of OOF Legacy
positioned elements. It was not the right fix.
https://chromium-review.googlesource.com/c/chromium/src/+/1649086
This fix backs out the original fix, and implements the correct fix:
OOF objects positioned by RunLegacyLayout could end up
with a cached layout result that had an old constraint space.
Fix is to force re-cache with new constraint space.
Bug: 970171
Change-Id: Ia9a7faea929083566f406db371ddcef058f2e4ab
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1652653
Commit-Queue: Aleks Totic <atotic@chromium.org>
Reviewed-by: Ian Kilpatrick <ikilpatrick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#668709}
--
wpt-commits: b8eea2d704ec32a88a3b8b46a2d01e96b3a470b5
wpt-pr: 17303
Automatic update from web-platform-tests
Load Ahem as a webfont everywhere (part 2) (#17173)
This change updates a large number of reftests to link to the
`/fonts/ahem.css` stylesheet. Each file contains a single additional
line before the first `<style>` element:
```
<link rel="stylesheet" type="text/css" href="/fonts/ahem.css" />
```
--
wp5At-commits: 9c780585758acf5e9ac6d17ad9bd03c83404c7e6
wpt-pr: 17173
Automatic update from web-platform-tests
[LayoutNG] Minor inline container DCHECK fix
We already had a fix for inline, misssed fixing
it for block.
Bug: 967977
Change-Id: Iad883eca7761f0db203fc6e01d48466d7b09dfd5
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1648299
Reviewed-by: Koji Ishii <kojii@chromium.org>
Commit-Queue: Aleks Totic <atotic@chromium.org>
Cr-Commit-Position: refs/heads/master@{#667249}
--
wp5At-commits: 72d169bb495070a1531d4fac4e8b60d3e5111679
wpt-pr: 17234
Automatic update from web-platform-tests
[LayoutNG] Only reset a legacy cached result if OOF-positioned.
We had an issue with our simplified layout algorithm + relayout boundary
roots.
For this to trigger we needed a (legacy) layout object to be marked for
simplified layout which was also a relayout boundary root.
During LocalFrameView::PerformLayout, LayoutBox::UpdateLayout would run
on the legacy LayoutBox, and during LayoutBox::UpdateAfterLayout, this
would clear the LayoutBox::cached_layout_result_.
During another relayout boundary layout, we'd trigger simplified layout
for an NG node. This expects that there is always a cached layout
result associated with a box.
However this now wasn't the case, as the child had previously cleared
it, within LayoutBox::UpdateAfterLayout.
The guard inside LayoutBox::UpdateAfterLayout was designed to protect
against OOF-positioned nodes changing their layout parent, this
modifies that check do only clear the layout result of OOF-positioned
legacy layout objects.
Bug: 963387, 963433, 963620
Change-Id: Ice1202bdb939689e26e24a8690a52e7d7e82ecbc
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1614082
Reviewed-by: Aleks Totic <atotic@chromium.org>
Commit-Queue: Ian Kilpatrick <ikilpatrick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#660166}
--
wp5At-commits: c40cd30b2d4d686325f3b00403c1c3d0314219e3
wpt-pr: 16859
Automatic update from web-platform-tests
[LayoutNG] Add the "simplified" layout pass.
This introduces the simplified layout algorithm. This is triggered when
- An OOF descendant has its constraints changed.
- The block-size of a fragment changes in size.
There are several nuanced details with this algorithm. E.g. determining
the correct static position for an OOF descendant.
Bug: 635619
Change-Id: Iba4c4b82edf873fa4cad9ba28e9fa3849a4a8e8e
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1590237
Commit-Queue: Ian Kilpatrick <ikilpatrick@chromium.org>
Reviewed-by: Koji Ishii <kojii@chromium.org>
Reviewed-by: Morten Stenshorne <mstensho@chromium.org>
Cr-Commit-Position: refs/heads/master@{#659745}
--
wp5At-commits: 20b091dca60176b03c6c6cd8466619dd9cf370e2
wpt-pr: 16738
Automatic update from web-platform-tests
Sticky positioning contributes to overflow at in-flow scroll position.
Even if a stickily positioned box sticks to the scrollport when
scrolling, that doesn't mean that the current distance to the start of
the scrollable container should make any difference during layout, as
far as overflow contribution from the stickily positioned box is
concerned.
Bug: 958803
Change-Id: I8a268c3ec2d5d62960f1f92322e75f932afe2a91
Cq-Include-Trybots: luci.chromium.try:linux_layout_tests_layout_ng
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1597588
Reviewed-by: Emil A Eklund <eae@chromium.org>
Reviewed-by: Aleks Totic <atotic@chromium.org>
Reviewed-by: Stephen McGruer <smcgruer@chromium.org>
Commit-Queue: Morten Stenshorne <mstensho@chromium.org>
Cr-Commit-Position: refs/heads/master@{#657467}
--
wpt-commits: 36b5d2e074d7fe19c027c1659640c53212096b53
wpt-pr: 16693
Automatic update from web-platform-tests
[LayoutNG] OOF inline containing block continuation cleanup
Inline containing block dimensions were computed incorrectly if:
- inline OOF container was split
- OOF Element was inside non-root continuation
This happened because container dimensions were computed by
finding all fragments whose layout object root matched inline_container.
If inline container was not a root, no fragments were found.
Actual fix is simple: ensure that NGOutOfFlowPositionedDescendant
always points to the root.
While fixing this, I also did a little bit of cleanup. Main change was
- change NGOutOfFlowPositionedDescendant.inline_container to LayoutInline*
from LayoutObject*
Bug: 931867
Change-Id: Ibd3c0e9fdeffaf2c63d3f59386bc2ea223ec726b
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1592528
Commit-Queue: Aleks Totic <atotic@chromium.org>
Reviewed-by: Ian Kilpatrick <ikilpatrick@chromium.org>
Reviewed-by: Morten Stenshorne <mstensho@chromium.org>
Cr-Commit-Position: refs/heads/master@{#656269}
--
wpt-commits: e45156b5e558c062a609356905c83a0258c516e3
wpt-pr: 16631
Automatic update from web-platform-tests
[LayoutNG] Fix GetChildOffset problem
Original code was wrong, and worked in many cases
by accident, because Parent() and ContainingBlock()
were the same element.
Bug: 945696
Change-Id: I3dfccdfcb743606856fe5d7d33948409bf89b9fa
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1589119
Reviewed-by: Christian Biesinger <cbiesinger@chromium.org>
Reviewed-by: Morten Stenshorne <mstensho@chromium.org>
Commit-Queue: Aleks Totic <atotic@chromium.org>
Cr-Commit-Position: refs/heads/master@{#655257}
--
wpt-commits: 4f26f67a4eb9aaae3c25beaa9a95b032bdbe68f6
wpt-pr: 16600
Automatic update from web-platform-tests
[LayoutNG] Fix OOF layout invalidation
MarkParentForOutOfFlowPositionedChange would skip chain invalidation
if elements in chain were already invalidated.
This change makes this occurrence less frequent.
Additional minor optimization I can make because I understand
MarkParentForOutOfFlowPositionedChange call sites:
LayoutBox::StyleWillChange used to call MarkParentForOutOfFlowPositionedChange
This is not necessary, because MarkParentForOutOfFlowPositionedChange is
also called by LayoutObject::StyleDidChange.
Legacy code fails the new test case. Cause of the failure is the same,
insufficient invalidation. But the fix needs to be different, becasue
Legacy does not call MarkParentForOutOfFlowPositionedChange.
Tentative legacy fix is, but I think applying it is not worth the risk.
--- a/third_party/blink/renderer/core/layout/layout_block_flow_line.cc
+++ b/third_party/blink/renderer/core/layout/layout_block_flow_line.cc
@@ -1978,6 +1978,7 @@ void LayoutBlockFlow::LayoutInlineChildren(bool relayout_children,
if (o->IsOutOfFlowPositioned()) {
o->ContainingBlock()->InsertPositionedObject(box);
+ o->MarkContainerChainForLayout();
Bug: 952644, 949615
Change-Id: Iaf7114660ae10cb9117b7a8b95e1e86c59d10dec
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1578358
Commit-Queue: Aleks Totic <atotic@chromium.org>
Reviewed-by: Morten Stenshorne <mstensho@chromium.org>
Reviewed-by: Koji Ishii <kojii@chromium.org>
Cr-Commit-Position: refs/heads/master@{#654879}
--
wpt-commits: 30af25af159c0207f02273c93f566b6598ff9e43
wpt-pr: 16453
Automatic update from web-platform-tests
Adding a test for crbug.com/942555
Unfortunately, due to crbug.com/895904 and crbug.com/567947,
this test isn't going to run on Android, which is where the original
bug occurs. But if crbug.com/567947 gets resolved, this test
can be enabled in SmokeTests.
Bug: 942555
Change-Id: Ibaa3e63d2f5f472961b30c34d39ab49344c8ecba
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1584849
Auto-Submit: Mason Freed <masonfreed@chromium.org>
Commit-Queue: Stephen Chenney <schenney@chromium.org>
Reviewed-by: Stephen Chenney <schenney@chromium.org>
Cr-Commit-Position: refs/heads/master@{#654939}
--
wpt-commits: a092f6dd48ea7602ed3089a8b0094d299e8360b2
wpt-pr: 16546
Automatic update from web-platform-tests
Call SetSubtreePropertyChanged in Layer::SetStickyPositionConstraint
Previously, changing the sticky position constraints on a layer (e.g.
changing the element's top value) would not cause a proper
invalidation. Due to this, the active tree would not realize the
TransformNode had changed nor that it needed to re-calculate the draw
properties.
To fix this, call SetSubtreePropertyChanged in
SetStickyPositionConstraint, similarly to SetTransform.
Bug: 939632
Change-Id: I9d7c68f0fd85d799e9807f7b8cc435d11659f2e3
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1577934
Reviewed-by: Philip Rogers <pdr@chromium.org>
Reviewed-by: Robert Flack <flackr@chromium.org>
Reviewed-by: weiliangc <weiliangc@chromium.org>
Commit-Queue: Stephen McGruer <smcgruer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#654170}
--
wpt-commits: 87e88df2e5073af55c834e99a56b8bc940cc383f
wpt-pr: 16539
Automatic update from web-platform-tests
OOF bugfix: mark container chain
This bug affected NG and Legacy.
If an OOF container was no longer an OOF container,
the new container needs to be marked for relayout.
This did not happen if there was a relayout boundary
between old and new OOF container.
The fix marks new container for relayout.
Bug: 949222
Change-Id: I676ea6d4b4fdbd989cbab08709b4977705250b67
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1555502
Commit-Queue: Aleks Totic <atotic@chromium.org>
Auto-Submit: Aleks Totic <atotic@chromium.org>
Reviewed-by: Ian Kilpatrick <ikilpatrick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#649527}
--
wpt-commits: 2d1cea9fdf329a1d7d03ecd505a8a216e57d85ba
wpt-pr: 16281
Automatic update from web-platform-tests
[LayoutNG] Fix nested legacy oof descendants
Another fix for "Legacy OOF descendant did not get laid out"
The cause here was:
- if #container had a legacy descendant, and
- legacy descendant had an oof descendant whose containing block was
#container, that oof descendant would get added to #container's list
of legacy oof, but would never get laid out.
This bug was hidden, because it would not happen if layout happened
twice, which we often do.
Seen in the wild at https://www.humblebundle.com/ when scrolling down.
Bug: 946986
Change-Id: I183f3d5dfe79b49c5c6aadad0ee2cfcb8bb6849f
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1546713
Commit-Queue: Aleks Totic <atotic@chromium.org>
Reviewed-by: Ian Kilpatrick <ikilpatrick@chromium.org>
Auto-Submit: Aleks Totic <atotic@chromium.org>
Cr-Commit-Position: refs/heads/master@{#646077}
--
wpt-commits: 94cd32e64d89b561b803355c299c9db5908e0cb1
wpt-pr: 16158
