fix(supports): keep the vendor prefix on a feature query inside and/or - #1316
Open
oddharsh wants to merge 1 commit into
Open
Conversation
The @supports merge pass bound the unprefixed id over `property_id` and then used that binding for two more things: what it stored, and which prefix it merged in. So a condition matching nothing already seen was pushed with its prefix stripped, and `(-webkit-box-orient: vertical)` became `(box-orient: vertical)`, which no browser implements. The block it guards then silently never applies. Using a separate binding for the match key fixes both. The unprefixed id is the KEY only; the condition keeps the prefix it was written with, and the merge branch now adds the real prefix rather than VendorPrefix::None. A prefixed query survives when it stands alone, because that path pushes `in_parens` untouched, which is why this reads as an odd inconsistency rather than a plain regression. Reducing a report to a single condition to check whether it still reproduces answers no on a build that is still broken. The tests that shipped with the feature all set `Browsers` targets, and the prefixing pass then re-adds what the merge dropped, so they could not catch it. The regression tests added here deliberately set none. Fixes parcel-bundler#710
oddharsh
added a commit
to oddharsh/site
that referenced
this pull request
Aug 26, 2026
…pstream (#596) parcel-bundler/lightningcss#1316. The merge pass binds the unprefixed id OVER `property_id` and then uses that binding for two more things, so a condition matching nothing already seen is stored stripped and the merge branch adds `VendorPrefix::None` rather than the real prefix. A separate binding for the match key fixes both; 120/120 of their lib tests pass and the three added regression tests fail without it. That mechanism also explains the compound trigger this entry had recorded as a bare observation. A lone condition takes the `conditions.push(in_parens.clone())` path and never reaches the merge, which is why it survives while an operand of and/or does not. The explanation was one commit away the whole time, and the entry had been sitting on a reproduction for a week without anyone opening the source. Worth remembering the next time a gotcha here stops at "reproduces on version N". Also marks the `:-moz-focusring` arm as a workaround with an expiry rather than a permanent shape, and says explicitly not to remove it early: this is the quiet failure direction, so nothing goes red when the bug returns. Co-authored-by: Aadharsh Pannirselvam <19518661+oddharsh@users.noreply.github.com>
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
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.
Fixes #710.
The
@supportsmerge pass binds the unprefixed id overproperty_id, and then uses that binding for two more things: what it stores, and which prefix it merges in.So a condition matching nothing already seen is pushed with its prefix gone, and
(-webkit-box-orient: vertical)becomes(box-orient: vertical)— which no browser implements, so the block it guards silently never applies.Using a separate binding for the match key fixes both symptoms. The unprefixed id is the key only; the condition keeps the prefix it was written with, and the merge branch adds the real prefix instead of
None.Why it reads as an inconsistency rather than a plain regression
A prefixed query survives when it stands alone, because that path pushes
in_parensuntouched. It is only stripped as an operand ofand/or. Measured on 1.33.0 before this change:(display:flex) or …(-webkit-box-orient:vertical)(box-orient:vertical)(-webkit-backdrop-filter:blur(1px))(backdrop-filter:blur(1px))(-moz-appearance:none)(appearance:none)Worth knowing for anyone triaging this: reducing a report to a single condition to check whether it still reproduces answers no on a build that is still broken.
Why the existing tests did not catch it
Every assertion added with the merge feature in 6bd2761 sets
Browserstargets, and the prefixing pass then re-adds what the merge dropped. The regression tests here deliberately set none, and they useminify_testrather thanprefix_testfor that reason.Verification
Before and after, same input,
minify: true, no targets:cargo fmtleaves both changed files untouched (it does reformatbundler.rs,selector.rsand an unrelatedlib.rsline under current rustfmt; those are deliberately not included here)