Block/Flexbox/Grid: floor content width and child stretch/available sizes at zero

[nicoburns]

Objective

Stacked on #1177. Several places computed "container (or grid area / flex line) size minus insets/margins" and passed the result on unfloored, so when padding/border or a child's margins exceed the container, children received negative known_dimensions / available_space / percentage bases — and in the flexbox case a negative used size.

Block (perform_final_layout_on_in_flow_children):

let container_inner_width = container_outer_width - resolved_content_box_inset.horizontal_axis_sum();
let stretch_width  = container_inner_width - item_non_auto_x_margin_sum;   // -> known_dimensions.width & available_space.width
let available_width = container_inner_width - item_non_auto_x_margin_sum;  // floats

All floored at zero (.max(0.0)), including the float-avoiding slot.stretch_width.max(min_auto_width) case.

Flexbox: the container's inner available space (determine_available_space), the cross-axis stretch size handed to items as a known dimension (determine_flex_base_size, the intrinsic-main-size pass), main_stretch_size, cross_stretch_size, and the final stretched cross size in determine_used_cross_size (line_cross_size - margins) are floored at zero. The last one is user-visible: a stretched item in a column container whose horizontal margins exceed the container width ended up with width = -20 in the final layout (Chrome: 0).

Grid: grid_area_size - margins in GridItem::available_space/keyword sizing and in align_and_position_item floored at zero (only measure-function inputs were affected; final item sizes were already floored).

This matches Blink, which never hands a child a negative constraint: CalculateChildAvailableSize → ShrinkLogicalSize(..).ClampNegativeToZero(), stretch resolves to max(border+padding, available − margins), fit-content to (available − margins).ClampNegativeToZero(), and ResolveInlineLength DCHECK_GE(available_size, 0).

Tests:

• Chrome-generated gentest fixtures block_margin_x_exceeds_container_width, block_padding_exceeds_container_width, flex_column_stretch_margin_x_exceeds_container_width (children width="0" at the margin/padding edge; all fail on main, pass here).
• tests/hand_written/negative_available_space.rs: block / flex-column / grid containers with a margin-overflowing leaf; asserts the leaf's measure function never sees a negative known dimension or definite available space and that the leaf is 0 wide (all three fail on main).
• All 6081 existing fixtures unchanged.

Context

Follow-up from the investigation in #1177 (negative inline widths were observed inside the discarded min-content pass that #1177 removes, but the arithmetic is wrong regardless). Downstream, DioxusLabs/blitz#835 additionally clamps Blitz's own margin/inset subtraction in inline layout; that covers a different subtraction (Blitz's, after known_dimensions/node_size override the available space) so both are kept.

I could not construct a grid fixture where Chrome and Taffy disagree on final layout (grid already floors item sizes; a %/1fr/wrapping grandchild under a 0-wide item resolves the same from −20 and 0), so the grid change is covered by the hand-written measure-input test only.

Link to Devin session: https://dioxus.staging.devinenterprise.com/sessions/3a0b8cc210c041d8955c841fb2a76a8e
Open in Devin Desktop: https://dioxus.staging.devinenterprise.com/desktop/session/3a0b8cc210c041d8955c841fb2a76a8e?variant=devin-insiders
Requested by: @nicoburns

[staging-devin-ai-integration]

🤖 Devin AI Engineer

I'll be helping with this pull request! Here's what you should know:

✅ I will automatically:

• Address comments on this PR that start with 'DevinAI' or '@devin'.
• Look at CI failures and help fix them

Note: I can only respond to comments from users who have write access to this repository.

⚙️ Control Options:

• Disable automatic comment, CI, and merge conflict monitoring