Bug 1458107 [wpt PR 10725] - [LayoutNG] Improve handling of adjoining floats., a=testonly

Automatic update from web-platform-tests[LayoutNG] Improve handling of adjoining floats.

A float always needs to be positioned by its block parent, so passing
them around to children, parents or siblings really shouldn't be
necessary (and it *was* somewhat confusing, since nobody but the direct
float parent is allowed to touch them anyway, apart from placing them
into temporary exclusion spaces). The main reason for passing them
around like that, was for other blocks to determine, based on the list
of floats being empty or not, the need for relayout once the BFC offset
was resolved.

Instead, confine the list of unpositioned floats to the block parent of
those floats, and introduce the concept of adjoining float types (none,
left, right, both). Adjoining floats occur when the BFC offset is
unknown, meaning that their position may be affected by the current
layout algorithm.

Adjoining float types will now be the thing that's both input to and
output from the layout algorithms. Having something other than "none"
means that a block's BFC offset is unknown, but that doesn't
automatically mean that we have to abort and re-layout if the BFC offset
gets resolved. If the "floats BFC offset" is known, for instance, those
adjoining floats may be positioned right away. Still we need to know
about them (positioned or not), to get clearance correct.

We're going to need to treat adjoining floats specially when applying
clearance. Will deal with that in a later CL. For now, we just keep
track of the adjoining float types, so that the clearance machinery can
tell that there are floats there that may not yet be positioned. That
used to be taken care of the list of unpositioned floats, but, as
previously stated, adjoining floats are special, and we need to know
about them, whether they are positioned or not. This is a preparatory CL
for that.

Each time we add an unpositioned float, we need to update the types of
adjoining floats, so that these can be returned from the algorithm if
necessary. Whether they end up being positioned right away or not isn't
relevant. Adjoining is adjoining.

Note that we don't have to #include the header file for unpositioned
floats as much as before now, but I'll clean that up in a follow-up CL,
because it turned out that there were quite a few translation units that
got stuff for free via that header file, instead of explicitly including
what they need.

Had to rewrite how we deal with floats in HandleNewFormattingContext()
and LayoutNewFormattingContext(), since those depended on a list of all
preceding unpositioned floats to place them into a temporary exclusion
space, to figure out whether to let the child's margin be adjoining with
the current margin strut or not. Instead of using a temporary exclusion
space, we now position floats via the regular mechanisms, and initially
assume that the child's margin is going to be adjoining. This means that
we have to abort and roll back if there are preceding unpositioned
floats. This is no different from how we lay out regular blocks, though.
What *is* different is that if it turns out that the child's margin has
to be separated from the strut, we'll have to abort and roll back
once *again* (but only once).

The algorithms now need to keep track of whether they need to abort if
the BFC offset *changes*, rather than if it is *resolved*. We only allow
the offset to resolve and optionally change *once* afterwards, though.

Cq-Include-Trybots: master.tryserver.chromium.linux:linux_layout_tests_layout_ng
Change-Id: Ie527d659213049f180ebedc764e1d7f4926a5876
Reviewed-on: https://chromium-review.googlesource.com/1030191
Commit-Queue: Morten Stenshorne <mstensho@chromium.org>
Reviewed-by: Ian Kilpatrick <ikilpatrick@chromium.org>
Reviewed-by: Koji Ishii <kojii@chromium.org>
Cr-Commit-Position: refs/heads/master@{#555314}

--

wpt-commits: 39563cf141605683bb8d76abb74eaa0c764d6c65
wpt-pr: 10725

testing/web-platform/meta/MANIFEST.json

@@ -49587,6 +49587,18 @@
      {}
     ]
    ],
+   "css/CSS2/floats/new-fc-beside-adjoining-float-2.html": [
+    [
+     "/css/CSS2/floats/new-fc-beside-adjoining-float-2.html",
+     [
+      [
+       "/css/reference/ref-filled-green-200px-square.html",
+       "=="
+      ]
+     ],
+     {}
+    ]
+   ],
    "css/CSS2/floats/new-fc-beside-adjoining-float.html": [
     [
      "/css/CSS2/floats/new-fc-beside-adjoining-float.html",
@@ -49599,6 +49611,18 @@
      {}
     ]
    ],
+   "css/CSS2/floats/new-fc-separates-from-float-2.html": [
+    [
+     "/css/CSS2/floats/new-fc-separates-from-float-2.html",
+     [
+      [
+       "/css/reference/ref-filled-green-200px-square.html",
+       "=="
+      ]
+     ],
+     {}
+    ]
+   ],
    "css/CSS2/floats/new-fc-separates-from-float.html": [
     [
      "/css/CSS2/floats/new-fc-separates-from-float.html",
@@ -448586,10 +448610,18 @@
    "7287e2ce42cab8fda1f63e97c98b664f0b49e9fb",
    "reftest"
   ],
+  "css/CSS2/floats/new-fc-beside-adjoining-float-2.html": [
+   "3f5a648154f288d3a78038daacb3810662aa8977",
+   "reftest"
+  ],
   "css/CSS2/floats/new-fc-beside-adjoining-float.html": [
    "f378062671d9de538e54c7dba552c2deab57baa4",
    "reftest"
   ],
+  "css/CSS2/floats/new-fc-separates-from-float-2.html": [
+   "91a4405707130a19100db1ccbaebb41b885531dd",
+   "reftest"
+  ],
   "css/CSS2/floats/new-fc-separates-from-float.html": [
    "357427f1d71d7137c1ba4c386ae25acc7712928e",
    "reftest"

testing/web-platform/tests/css/CSS2/floats/new-fc-beside-adjoining-float-2.html

@@ -0,0 +1,16 @@
+<!DOCTYPE html>
+<title>A new formatting context that fits beside an adjoining float, and thus pulls down the float with its top margin</title>
+<link rel="author" title="Morten Stenshorne" href="mstensho@chromium.org">
+<link rel="help" href="https://www.w3.org/TR/CSS22/visuren.html#bfc-next-to-float" title="9.5 Floats">
+<link rel="help" href="https://www.w3.org/TR/CSS22/visuren.html#flow-control" title="9.5.2 Controlling flow next to floats: the 'clear' property">
+<meta name="assert" content="The float is adjoining with the box that establishes a new formatting context when it fits beside it, and will therefore be affected by its margin">
+<link rel="match" href="../../reference/ref-filled-green-200px-square.html">
+<p>Test passes if there is a filled green square and <strong>no red</strong>.</p>
+<div style="overflow:hidden; width:200px; height:200px; background:red;">
+  <div style="margin-top:190px;">
+    <div>
+      <div style="float:left; width:100px; height:200px; background:green;"></div>
+    </div>
+    <div style="margin-top:-190px; overflow:hidden; width:100px; height:200px; background:green;"></div>
+  </div>
+</div>

testing/web-platform/tests/css/CSS2/floats/new-fc-separates-from-float-2.html

@@ -0,0 +1,16 @@
+<!DOCTYPE html>
+<title>A new formatting context that doesn't fit beside a float make the float non-adjoining</title>
+<link rel="author" title="Morten Stenshorne" href="mstensho@chromium.org">
+<link rel="help" href="https://www.w3.org/TR/CSS22/visuren.html#bfc-next-to-float" title="9.5 Floats">
+<link rel="help" href="https://www.w3.org/TR/CSS22/visuren.html#flow-control" title="9.5.2 Controlling flow next to floats: the 'clear' property">
+<meta name="assert" content="Although the 'clear' property isn't specified in this test, a new formatting context that doesn't fit below a float that would otherwise be adjoining will need to separate its margin from the float, so that it doesn't affect the float. This is very similar to clearance.">
+<link rel="match" href="../../reference/ref-filled-green-200px-square.html">
+<p>Test passes if there is a filled green square and <strong>no red</strong>.</p>
+<div style="overflow:hidden; width:200px; height:200px; background:red;">
+  <div style="margin-top:-50px;">
+    <div>
+      <div style="float:left; width:200px; height:150px; background:green;"></div>
+    </div>
+    <div style="margin-top:12345px; overflow:hidden; width:200px; height:100px; background:green;"></div>
+  </div>
+</div>