Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 6338be7750407682e1b45f0c9cb227ec5be4da63
      
https://github.com/WebKit/WebKit/commit/6338be7750407682e1b45f0c9cb227ec5be4da63
  Author: Chris Dumez <[email protected]>
  Date:   2026-06-19 (Fri, 19 Jun 2026)

  Changed paths:
    A 
LayoutTests/imported/w3c/web-platform-tests/css/css-values/calc-dimension-serialization-order-expected.txt
    A 
LayoutTests/imported/w3c/web-platform-tests/css/css-values/calc-dimension-serialization-order.html
    M Source/WebCore/css/calc/CSSCalcTree+Serialization.cpp

  Log Message:
  -----------
  calc() serializes 'vmax' in the wrong order relative to other dimensions
https://bugs.webkit.org/show_bug.cgi?id=317468

Reviewed by Darin Adler and Sam Weinig.

When serializing a calc() Sum or Product, its dimension children must be sorted
by their unit, ordered ASCII case-insensitively, per:
- https://drafts.csswg.org/css-values-4/#sort-a-calculations-children

sortPriority() hand-numbered each unit's sort key. 'vmax' was given the key 50,
which both collided with 'svb' (also 50) and skipped the intended slot 60
between 'vi' (59) and 'vmin' (61). As a result 'vmax' sorted ahead of every unit
in the 50-59 range that it should have followed (svh, svi, svmax, svmin, svw,
turn, vb, vh, vi), so e.g. calc(1vmax + 1vh) serialized as "calc(1vmax + 1vh)"
instead of the canonical "calc(1vh + 1vmax)".

Rather than just correct the one key, assign the keys sequentially via 
__COUNTER__
so that this whole class of bug (a collision or a skipped slot from 
hand-numbering)
becomes impossible: adding, removing or reordering a case now renumbers
automatically. The base is captured once so the keys still start at 0 regardless
of any earlier __COUNTER__ use in the translation unit, and the two sentinels 
that
must sort after every real unit (the unreachable error case and non-numeric
children) are derived from std::numeric_limits so they no longer depend on the
unit count. The resulting keys are identical to the hand-numbered ones, except
'vmax' now correctly gets 60.

Add an exhaustive (but fast) test that exercises the full ordering. It lists
every relative-length unit that survives calc() simplification as a distinct
term (the font-relative, container-query and viewport units, plus px standing
in for the absolute lengths that all canonicalize to px) plus a leading
percentage, in canonical order. It then (a) feeds them all in reverse order and
checks they serialize back in canonical order, and (b) sweeps every adjacent
pair, swapping the two and checking they serialize back sorted -- which
pinpoints any single out-of-place unit, exactly the failure mode of the 'vmax'
bug ('vmax' was caught by the 'vmax sorts after vi' and 'vmin sorts after vmax'
pairs).

Test: 
imported/w3c/web-platform-tests/css/css-values/calc-dimension-serialization-order.html

* 
LayoutTests/imported/w3c/web-platform-tests/css/css-values/calc-dimension-serialization-order-expected.txt:
 Added.
* 
LayoutTests/imported/w3c/web-platform-tests/css/css-values/calc-dimension-serialization-order.html:
 Added.
* Source/WebCore/css/calc/CSSCalcTree+Serialization.cpp:
(WebCore::CSSCalc::sortPriority):

Canonical link: https://commits.webkit.org/315557@main



To unsubscribe from these emails, change your notification settings at 
https://github.com/WebKit/WebKit/settings/notifications

Reply via email to