Bug 1539638 [wpt PR 16079] - [LayoutNG] Ignore cached min/max widths tainted by extrinsics., a=testonly
authorMorten Stenshorne <mstensho@chromium.org>
Thu, 18 Apr 2019 11:55:51 +0000
changeset 529925 8b1089b0d5a7ace550ab5df2e5bf1bf6b246e63a
parent 529924 fce66bb9c232b302dd985f60f5f7ac0b4e0f12c3
child 529926 7b8f7a84aefb5d0a0d9a11d728613a0187c76bff
push id11265
push userffxbld-merge
push dateMon, 13 May 2019 10:53:39 +0000
treeherdermozilla-beta@77e0fe8dbdd3 [default view] [failures only]
perfherder[talos] [build metrics] [platform microbench] (compared to previous push)
bugs1539638, 16079, 932979, 1538085, 644319
first release with
nightly linux32
nightly linux64
nightly mac
nightly win32
nightly win64
last release without
nightly linux32
nightly linux64
nightly mac
nightly win32
nightly win64
Bug 1539638 [wpt PR 16079] - [LayoutNG] Ignore cached min/max widths tainted by extrinsics., a=testonly Automatic update from web-platform-tests [LayoutNG] Ignore cached min/max widths tainted by extrinsics. Some properties (e.g. percentage padding) cause the cached min/max preferred inline sizes to be affected by the extrinsic size calculation. We store preferred min/max *border box* sizes. When a shrink-to-fit container has percentage-based inline padding, the resolved percentage padding is part of the preferred size. So, what we store is no longer purely intrinsic in this case, since percentages are resolved against something on the outside. The values need to be updated if the size of the containing block changes. Therefore, never re-use a previously calculated min/max preferred inline size in such cases. Remove code from NGBlockNode::Layout() which attempted to cope with such situations by using the legacy layout engine to recalculate min/max values. This doesn't work, because the legacy layout engine hasn't been updated with the new containing block size at this point (which are needed in order to resolve percentages correctly). Bug: 932979 Change-Id: I884bb2777babe9dae785055bac5029d7ea941a66 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1538085 Commit-Queue: Ian Kilpatrick <ikilpatrick@chromium.org> Reviewed-by: Koji Ishii <kojii@chromium.org> Reviewed-by: Ian Kilpatrick <ikilpatrick@chromium.org> Cr-Commit-Position: refs/heads/master@{#644319} -- wpt-commits: c3be5b409630ad5d6c82f22e24216383dcb53426 wpt-pr: 16079
new file mode 100644
--- /dev/null
+++ b/testing/web-platform/tests/css/css-sizing/fit-content-percentage-padding.html
@@ -0,0 +1,30 @@
+<!DOCTYPE html>
+<link rel="author" title="Morten Stenshorne" href="mailto:mstensho@chromium.org">
+<link rel="help" href="https://www.w3.org/TR/CSS22/box.html#propdef-padding-left">
+<link rel="help" href="https://www.w3.org/TR/css-sizing-3/#valdef-width-fit-content-length-percentage">
+<meta name="assert" content="The shrink-to-fit container (#stf) should be just wide enough to fit both floats beside each other. The percentage padding shouldn't be affected by intrinsic sizing; it's simply resolved from its containing block (#container), which doesn't participate in the intrinsic size calculation at all.">
+<div id="container" style="width:400px; height:200px;">
+  <div id="stf" style="width:fit-content; padding-left:20%;">
+    <div style="float:left; width:50px; height:100px; background:cyan;"></div>
+    <div style="float:left; width:50px; height:100px; background:hotpink;"></div>
+  </div>
+<script src="/resources/testharness.js"></script>
+<script src="/resources/testharnessreport.js"></script>
+  var container = document.getElementById("container");
+  var stf = document.getElementById("stf");
+  test(()=> {
+      assert_equals(stf.offsetWidth, 180);
+  }, "Initial layout");
+  test(()=> {
+      container.style.width = "300px";
+      assert_equals(stf.offsetWidth, 160);
+  }, "Shrink width");
+  test(()=> {
+      container.style.width = "500px";
+      assert_equals(stf.offsetWidth, 200);
+  }, "Grow width");