Fix text-shadow parsing: negative/decimal lengths and color ordering#507
Open
durvesh1992 wants to merge 2 commits into
Open
Fix text-shadow parsing: negative/decimal lengths and color ordering#507durvesh1992 wants to merge 2 commits into
durvesh1992 wants to merge 2 commits into
Conversation
The length regex used to detect whether the final token of a text-shadow
is a length or a color only matched non-negative integer lengths (e.g.
"3px"). As a result, a trailing negative offset ("1px -2px") or a
trailing decimal blur radius ("1px 1px 2.5px") was misclassified as the
color, dropping the offset/blur and producing a bogus color value.
Allow an optional leading minus sign and decimal values in the length
regex, matching the pattern already used by CSSLengthUnitValue.
Add unit tests covering negative offsets and decimal blur radii with and
without an explicit color.
CSS allows the text-shadow color to appear either before or after the offset values. parseValue only inspected the last token, so a leading color (e.g. "red 1px 1px") was misparsed: the color was dropped and the first offset became the color string. Detect the color as the single non-length token regardless of position.
durvesh1992
changed the title
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Fixes a few related correctness bugs in
parseTextShadow(native), all stemming from how the parser distinguishes a length token from the color token.1. Negative and decimal lengths
LENGTH_REGonly matched non-negative integer lengths (e.g.3px). When the last token was a negative offset or a decimal blur radius with no explicit color, it was misclassified as the color — dropping the offset/blur and producing a bogus color value:text-shadow: 1px -2px→ vertical offset dropped,textShadowColorset to"-2px"text-shadow: 1px 1px 2.5px→ blur dropped,textShadowColorset to"2.5px"Fixed by allowing an optional leading minus sign and decimals in
LENGTH_REG, matching the pattern already used byCSSLengthUnitValue.2. Color specified before the offsets
CSS allows the color to appear either before or after the offset values, but
parseValueonly inspected the last token. A leading color was misparsed:text-shadow: red 1px 2px 3px→ color dropped,offsetXbecame"red"Fixed by detecting the color as the single non-length token regardless of position.
Test plan
Added unit tests covering negative offsets, decimal blur radii, and color-before/after ordering (failing before, passing after). Full jest suite passes (901 tests),
flow checkreports no errors, andeslintis clean.