From 7670ef9fed14bb06211215c193290f6eee9675c0 Mon Sep 17 00:00:00 2001
From: Nico Burns <nico@nicoburns.com>
Date: Mon, 26 Dec 2022 16:43:54 +0000
Subject: [PATCH] Avoid call to measure child by reusing the already-computed
 resolved_minimum_size (#294)

* Avoid call to measure child by reusing the already-computed resolved_minimum_size

* cargo fmt
---
 src/compute/flexbox.rs | 31 +++++++++++++++++--------------
 1 file changed, 17 insertions(+), 14 deletions(-)

diff --git a/src/compute/flexbox.rs b/src/compute/flexbox.rs
index 6fcec3819..c1dfa2159 100644
--- a/src/compute/flexbox.rs
+++ b/src/compute/flexbox.rs
@@ -240,7 +240,7 @@ fn compute_preliminary(
     #[cfg(feature = "debug")]
     NODE_LOGGER.log("resolve_flexible_lengths");
     for line in &mut flex_lines {
-        resolve_flexible_lengths(tree, line, &constants, original_gap, available_space);
+        resolve_flexible_lengths(tree, line, &constants, original_gap);
     }
 
     // TODO: Cleanup and make according to spec
@@ -715,7 +715,6 @@ fn resolve_flexible_lengths(
     line: &mut FlexLine,
     constants: &AlgoConstants,
     original_gap: Size<f32>,
-    available_space: Size<AvailableSpace>,
 ) {
     let total_original_main_axis_gap = sum_axis_gaps(original_gap.main(constants.dir), line.items.len());
     let total_main_axis_gap = sum_axis_gaps(constants.gap.main(constants.dir), line.items.len());
@@ -739,21 +738,25 @@ fn resolve_flexible_lengths(
     //      smaller than its hypothetical main size
 
     for child in line.items.iter_mut() {
-        // TODO - This is not found by reading the spec. Maybe this can be done in some other place
-        // instead. This was found by trail and error fixing tests to align with webkit output.
+        // This is somewhat bizarre in that it's asymetrical depending whether the flex container is a column or a row.
+        //
+        // I *think* this might relate to https://drafts.csswg.org/css-flexbox-1/#algo-main-container:
+        //
+        //    "The automatic block size of a block-level flex container is its max-content size."
+        //
+        // Which could suggest that flex-basis defining a vertical size does not shrink because it is in the block axis, and the automatic size
+        // in the block axis is a MAX content size. Whereas a flex-basis defining a horizontal size does shrink because the automatic size in
+        // inline axis is MIN content size (although I don't have a reference for that).
+        //
+        // Ultimately, this was not found by reading the spec, but by trial and error fixing tests to align with Webkit/Firefox output.
+        // (see the `flex_basis_unconstraint_row` and `flex_basis_uncontraint_column` generated tests which demonstrate this)
         if constants.node_inner_size.main(constants.dir).is_none() && constants.is_row {
             child.target_size.set_main(
                 constants.dir,
-                compute_node_layout(
-                    tree,
-                    child.node,
-                    child.size.maybe_clamp(child.min_size, child.max_size),
-                    available_space,
-                    RunMode::ComputeSize,
-                    SizingMode::ContentSize,
-                )
-                .main(constants.dir)
-                .maybe_clamp(child.min_size.main(constants.dir), child.max_size.main(constants.dir)),
+                child.size.main(constants.dir).unwrap_or(0.0).maybe_clamp(
+                    child.resolved_minimum_size.main(constants.dir).into(),
+                    child.max_size.main(constants.dir),
+                ),
             );
         } else {
             child.target_size.set_main(constants.dir, child.hypothetical_inner_size.main(constants.dir));