Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: 0ca045f5e7c02f2ed6935cb5131f40643cc5ee3f
https://github.com/WebKit/WebKit/commit/0ca045f5e7c02f2ed6935cb5131f40643cc5ee3f
Author: Ahmad Saleem <[email protected]>
Date: 2026-08-26 (Wed, 26 Aug 2026)
Changed paths:
M LayoutTests/svg/dom/SVGAngle-expected.txt
M LayoutTests/svg/dom/SVGAngle.html
M Source/WebCore/svg/SVGAngleValue.cpp
Log Message:
-----------
Adopt CSS parser machinery for parsing SVGAngleValue
https://bugs.webkit.org/show_bug.cgi?id=321907
rdar://185080341
Reviewed by Sam Weinig.
SVGAngleValue::setValueAsString() hand-rolled its parsing on top of
SVGParserUtilities: parseNumber() followed by a parseAngleType() helper that
switched on the buffer's remaining length and compared characters directly.
Replace it with the shared CSS property-parser machinery, the way SVGLengthValue
was modernized in 298731@main: tokenize with CSSTokenizer under a
SVGAttributeMode parser context, then consume via
MetaConsumer<CSS::NumberRaw<>, CSS::AngleRaw<>>.
MetaConsumer avoids allocating a throwaway CSSPrimitiveValue, and the Raw types
have no FunctionToken consumer, so calc() is rejected structurally rather than
consumed and then discarded (FIXME to support it, matching SVGLengthValue and
every other engine). CSS::NumberRaw<> must come first: the unroller tries types
in order, and CSS::AngleRaw<> would otherwise take a unitless value as degrees
instead of leaving it SVG_ANGLETYPE_UNSPECIFIED.
Whitespace is handled on the token range, not the string: consumeWhitespace()
for the leading run, and each consumer already ends with
consumeIncludingWhitespace() so the trailing run is gone before atEnd() is
checked. The tokenizer's whitespace set is exactly isASCIIWhitespace()'s, so
this accepts what a StringView::trim() would have without the copy.
An FLT_MAX check remains because unresolved CSS numeric types always store a
double regardless of their ResolvedValueType (see CSSPrimitiveNumericRaw.h) and
CSS::All neither rejects nor clamps; it keeps the old rejection of values like
"1e39deg" that the float member cannot represent. Past DBL_MAX the tokenizer
yields an infinity that the consumers reject on their own.
Since the <angle> in SVG attributes is a CSS <angle>, its unit is now matched
ASCII case-insensitively, so "5Rad" and "5graD" parse instead of throwing, in
line with SVG length attributes. Sharing the tokenizer likewise means comments
and identifier escapes are accepted, as they already are for lengths.
Precision improves as a side effect: the old parser accumulated in float and
multiplied by a float-narrowed power of ten, so "5e-2deg" landed on 0.049999997.
It now computes 0.05 as a double and narrows once.
SVGAngle.html asserted that "5graD" and "5Rad" throw; those are replaced by a
block covering all four units in mixed case, where "5TurN" reports
SVG_ANGLETYPE_UNKNOWN because SVGAngle.idl exposes no TURN constant and
unitType() clamps above GRAD per specification, while valueAsString still
round-trips "5turn". Added coverage for the float and double boundaries in both
directions, and a calc() block written against the behavior we want, so the
FIXME is tracked by the baseline rather than only by a comment.
* LayoutTests/svg/dom/SVGAngle-expected.txt: Rebaselined.
* LayoutTests/svg/dom/SVGAngle.html: Add test cases for case-insensitive units,
calc(), and the float/double range boundaries.
* Source/WebCore/svg/SVGAngleValue.cpp:
(WebCore::cssAngleUnitToSVGAngleType):
(WebCore::SVGAngleValue::setValueAsString):
(WebCore::parseAngleType): Deleted.
Canonical link: https://commits.webkit.org/319893@main
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
