Bug 1523562 [wpt PR 14997] - Recalculate preferred widths on layout when necessary., a=testonly
authorMorten Stenshorne <mstensho@chromium.org>
Thu, 31 Jan 2019 18:59:23 +0000
changeset 458088 8dc4da778d4d153a0dc739683663e4766602761e
parent 458087 dadb5e460082fd5532f43885e3331dbf380d1ab4
child 458089 492a748b9d5468661fc752fb138b08a2eba65011
push id35518
push useropoprus@mozilla.com
push dateFri, 08 Feb 2019 09:55:14 +0000
treeherdermozilla-central@3a3e393396f4 [default view] [failures only]
perfherder[talos] [build metrics] [platform microbench] (compared to previous push)
bugs1523562, 14997, 923568, 1426677, 624919
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 1523562 [wpt PR 14997] - Recalculate preferred widths on layout when necessary., a=testonly Automatic update from web-platform-tests Recalculate preferred widths on layout when necessary. Some objects take the size of the containing block as input when calculating preferred inline-size, contrary to common sense; see the NeedsPreferredWidthsRecalculation() documentation in LayoutBox. In such cases we may need to recalculate the preferred inline-size as part of layout, even if no content inside changed. At the same time, we need to be careful not to do unnecessary work here. There is an optimization that just refuses to update preferred inline-size if it was already marked dirty, because the assumption then is that the preferred inline-size will in fact never be needed. This optimization caused trouble for the other optimization, which checks if the containing block also is a special object that needs this kind of preferred inline-size calculation as part of layout, because if it does, the idea is that the containing block will already have taken care of it as part of walking the subtree. The missing part here was to check if the containing block actually would calculate its preferred inline-size at all (or if it was skipped due the first optimization). Fixed that. Bug: 923568 Change-Id: I66064ee46de4769c9dc25d7ade727f6ccdc5d7c6 Reviewed-on: https://chromium-review.googlesource.com/c/1426677 Commit-Queue: Emil A Eklund <eae@chromium.org> Reviewed-by: Emil A Eklund <eae@chromium.org> Cr-Commit-Position: refs/heads/master@{#624919} -- wpt-commits: 538eac8f698febbc6a4629b1269077ba0aff6c1b wpt-pr: 14997
new file mode 100644
--- /dev/null
+++ b/testing/web-platform/tests/css/css-sizing/aspect-ratio-affects-container-width-when-height-changes.html
@@ -0,0 +1,22 @@
+<!DOCTYPE html>
+<link rel="author" title="Morten Stenshorne" href="mailto:mstensho@chromium.org">
+<link rel="help" href="https://www.w3.org/TR/css-sizing-3/#intrinsic-sizes">
+<p>There should be a green square below, and no red.</p>
+<div id="container" style="height:200px;">
+  <div style="height:100%;" data-expected-height="100">
+    <div style="float:left; height:100%; background:red;" data-expected-width="100" data-expected-height="100">
+      <!-- The image is a 1x1 transparent one. -->
+      <img style="display:block; height:100%; background:green;" src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" data-expected-width="100" data-expected-height="100">
+    </div>
+  </div>
+<script src="/resources/testharness.js"></script>
+<script src="/resources/testharnessreport.js"></script>
+<script src="/resources/check-layout-th.js"></script>
+  test(()=> {
+      document.body.offsetTop;
+      document.getElementById("container").style.height = "100px";
+      checkLayout("#container");
+  }, "Changing height should affect the descendant widths, due to aspect ratio");