[v6] ::placeholder & keyframes rejected in production build with enableVendorPrefixes

[mAAdhaTTah]

Environment

System:

• OS: macOS 12.6
• CPU: (16) x64 Intel(R) Core(TM) i9-9880H CPU @ 2.30GHz
• Memory: 112.43 MB / 16.00 GB
• Shell: 5.2.15 - /usr/local/bin/bash

Binaries:

• Node: 16.18.1 - ~/.nvm/versions/node/v16.18.1/bin/node
• Yarn: 1.22.19 - /usr/local/bin/yarn
• npm: 8.19.2 - ~/.nvm/versions/node/v16.18.1/bin/npm

Reproduction

https://github.com/mAAdhaTTah/sc-issue-4007

Steps to reproduce

1. Run npm start
2. Open localhost:3000
3. See the (correct) green placeholder in the input.
4. Run npm run build && npx serve build
5. Open localhost:3000
6. See the (incorrect) grey placeholder

Expected Behavior

::placeholder works in dev & prod mode.

Actual Behavior

::placeholder is stripped in prod mode.

[Sambhav399]

Hi @mAAdhaTTah can you please use LTS version of styled-components which is 5.3.10.

Also without your code snippet it's hard to understand what you are trying to explain.

[mAAdhaTTah]

@Sambhav399 I can't use the LTS version because I'm trying to upgrade to React 18, which didn't work with v5, hence starting the upgrade to v6.

As for a code snippet, I can try to provide a fuller example (this one doesn't seem to run after exporting from CodeSandbox), but basically I have an input that looks like this. The ::placeholder rule works in development but not production.

[mAAdhaTTah]

Ok, I have a reproduction example in this repo:

https://github.com/mAAdhaTTah/sc-issue-4007

If you git clone, npm i, then npm start, you'll see the site come up with a green placeholder. If you then run npm run build then npx serve build, and load up loadhost:3000, you see the placeholder is back to it's default grey.

[Sambhav399]

hi @mAAdhaTTah It's working fine on my side.
please have a look

[mAAdhaTTah]

Did you test by running npm run build && npx serve build? Cuz this is what I see running it that way:

[mAAdhaTTah]

I have updated the original issue with the reproduction & steps to reproduce, highlighting the difference in behavior between dev & production mode.

[mAAdhaTTah]

I'm also experiencing a keyframes bug in production. I've updated the example to include that issue.

[mAAdhaTTah]

@probablyup Happy to spend some time on this myself or put a dev on this if you're able to give us a lead as to where the issue might be.

[quantizor]

Usually when something doesn't work in production but does work locally it's because the CSSOM API rejected a rule we tried to insert. If you put a debugger here you should be able to see the rule as it fails the try block.

[quantizor]

That being said, it seems to work with latest SC: https://codesandbox.io/s/styled-components-v6-sandbox-forked-n9bkqn?file=/src/App.tsx

[mAAdhaTTah]

@probablyup CodeSandbox runs in development mode so it won't be reproducible there. I'll take a look at the try/catch block.

[mAAdhaTTah]

I was able to extract an error from the build version:

error inserting rule DOMException: Failed to execute 'insertRule' on 'CSSStyleSheet': Failed to parse the rule '.kOSysT:disabled ::-webkit-input-placeholder{color:#A69991;}.kOSysT:disabled ::-moz-placeholder{color:#A69991;}.kOSysT:disabled :-ms-input-placeholder{color:#A69991;}.kOSysT:disabled ::placeholder{color:#A69991;}'.
    at e.insertRule (http://localhost:3000/743.6ca781eb.iframe.bundle.js:6:4191814)
    at e.insertRules (http://localhost:3000/743.6ca781eb.iframe.bundle.js:6:4189816)
    at e.insertRules (http://localhost:3000/743.6ca781eb.iframe.bundle.js:6:4194055)
    at e.generateAndInjectStyles (http://localhost:3000/743.6ca781eb.iframe.bundle.js:6:4199579)
    at http://localhost:3000/743.6ca781eb.iframe.bundle.js:6:4201588
    at http://localhost:3000/743.6ca781eb.iframe.bundle.js:6:4201641
    at N (http://localhost:3000/743.6ca781eb.iframe.bundle.js:6:4201792)
    at Xh (http://localhost:3000/743.6ca781eb.iframe.bundle.js:6:3780838)
    at Zi (http://localhost:3000/743.6ca781eb.iframe.bundle.js:6:3790819)
    at Wk (http://localhost:3000/743.6ca781eb.iframe.bundle.js:6:3839509)

My guess is this is because we have enableVendorPrefixes turned on.

[mAAdhaTTah]

I've update the title (again!) to reflect the underlying issue.

[quantizor]

Could you post the actual code you're working on? There seems to be a space before the placeholder selector which is causing the issue.

Edit: nvm see the repro, but it doesn't match what you posted as an error as there is no [disabled] styling in your repo as far as I can tell

[mAAdhaTTah]

@probablyup No, sorry, I got the repro from my actual application, not the repro. I can grab from there if that's helpful.

[mAAdhaTTah]

Here's the errors from the reproduction:

10:31:54.093 emotion-unitless.esm.js:48 inserting rule 0 .kRrqli{padding:4em;background:papayawhip;}
10:31:54.095 emotion-unitless.esm.js:48 inserting rule 1 .jUqIfC{font-size:1.5em;}
10:31:54.095 emotion-unitless.esm.js:48 inserting rule 2 .jUqIfC::-webkit-input-placeholder{color:green;}.jUqIfC::-moz-placeholder{color:green;}.jUqIfC:-ms-input-placeholder{color:green;}.jUqIfC::placeholder{color:green;}
10:31:54.095 emotion-unitless.esm.js:48 error inserting rule DOMException: Failed to execute 'insertRule' on 'CSSStyleSheet': Failed to parse the rule '.jUqIfC::-webkit-input-placeholder{color:green;}.jUqIfC::-moz-placeholder{color:green;}.jUqIfC:-ms-input-placeholder{color:green;}.jUqIfC::placeholder{color:green;}'.
    at e.insertRule (http://localhost:3000/static/js/main.e3e32077.js:2:158684)
    at e.insertRules (http://localhost:3000/static/js/main.e3e32077.js:2:156700)
    at e.insertRules (http://localhost:3000/static/js/main.e3e32077.js:2:160903)
    at e.generateAndInjectStyles (http://localhost:3000/static/js/main.e3e32077.js:2:165899)
    at http://localhost:3000/static/js/main.e3e32077.js:2:167863
    at http://localhost:3000/static/js/main.e3e32077.js:2:167917
    at w (http://localhost:3000/static/js/main.e3e32077.js:2:168066)
    at _o (http://localhost:3000/static/js/main.e3e32077.js:2:63145)
    at ki (http://localhost:3000/static/js/main.e3e32077.js:2:73255)
    at _u (http://localhost:3000/static/js/main.e3e32077.js:2:122321)
10:31:54.099 emotion-unitless.esm.js:48 inserting rule 2 @-webkit-keyframes QuPkj{0%{-webkit-transform:rotate(0deg);-moz-transform:rotate(0deg);-ms-transform:rotate(0deg);transform:rotate(0deg);}100%{-webkit-transform:rotate(359deg);-moz-transform:rotate(359deg);-ms-transform:rotate(359deg);transform:rotate(359deg);}}@keyframes QuPkj{0%{-webkit-transform:rotate(0deg);-moz-transform:rotate(0deg);-ms-transform:rotate(0deg);transform:rotate(0deg);}100%{-webkit-transform:rotate(359deg);-moz-transform:rotate(359deg);-ms-transform:rotate(359deg);transform:rotate(359deg);}}
10:31:54.099 emotion-unitless.esm.js:48 error inserting rule DOMException: Failed to execute 'insertRule' on 'CSSStyleSheet': Failed to parse the rule '@-webkit-keyframes QuPkj{0%{-webkit-transform:rotate(0deg);-moz-transform:rotate(0deg);-ms-transform:rotate(0deg);transform:rotate(0deg);}100%{-webkit-transform:rotate(359deg);-moz-transform:rotate(359deg);-ms-transform:rotate(359deg);transform:rotate(359deg);}}@keyframes QuPkj{0%{-webkit-transform:rotate(0deg);-moz-transform:rotate(0deg);-ms-transform:rotate(0deg);transform:rotate(0deg);}100%{-webkit-transform:rotate(359deg);-moz-transform:rotate(359deg);-ms-transform:rotate(359deg);transform:rotate(359deg);}}'.
    at e.insertRule (http://localhost:3000/static/js/main.e3e32077.js:2:158684)
    at e.insertRules (http://localhost:3000/static/js/main.e3e32077.js:2:156700)
    at e.insertRules (http://localhost:3000/static/js/main.e3e32077.js:2:160903)
    at e.inject (http://localhost:3000/static/js/main.e3e32077.js:2:163959)
    at xt (http://localhost:3000/static/js/main.e3e32077.js:2:165055)
    at http://localhost:3000/static/js/main.e3e32077.js:2:165146
    at Array.flatMap (<anonymous>)
    at xt (http://localhost:3000/static/js/main.e3e32077.js:2:165118)
    at e.generateAndInjectStyles (http://localhost:3000/static/js/main.e3e32077.js:2:165756)
    at http://localhost:3000/static/js/main.e3e32077.js:2:167863
10:31:54.099 emotion-unitless.esm.js:48 inserting rule 2 .GZzXb{display:inline-block;-webkit-animation:QuPkj 1s infinite;animation:QuPkj 1s infinite;}

[mAAdhaTTah]

Can also confirm that adding window.SC_DISABLE_SPEEDY = true; before the JS loads functions as a workaround for now.

[quantizor]

Ah, I see. The vendor prefixed styles are supposed to be inserted separately, will look into it.

[quantizor]

Could y'all try styled-components@6.0.0-rc.2-4007 and let me know how it goes? It's this PR on top of main #4021

[quantizor]

Nvm I found some further problematic scenarios... need to spend more time on it

[mAAdhaTTah]

Ok great, happy to test or help out if there's anything I can do here.

[quantizor]

I'm kind of stuck due to some stylis behavior... basically the way stylis's prefixer works in v4 is the vendor-prefixed styles get stringified together into a lump instead of being emitted as separate discrete rules. This by itself is not hard to work around, but when you add wrappers like @media queries things get complicated based on the way things get binned.

@Andarist if you guys figured out a workaround for this would love to know. I see emotion pinned the prefixing engine to an earlier iteration but I suspect you'll have the same issue as CSSOM injection time if multiple prefixes are in the same committed rule?

[Andarist]

what exact call throws in the browser? what exact arguments are being passed to the browser API? in Emotion we wrap insertRule with try/catch (here) to avoid some problems with unknown pseudo selectors etc. I'm not sure if this issue here is about that though, just skimmed through it - if you could put up a TLDR summary for me... I would appreciate it 😅

[quantizor]

Haha sorry, will write up something more cohesive to use moving forward for discussion

[quantizor]

This has been partially resolved in RC.3. See the release notes for more info, there's some work that needs to happen on the stylis side for complete resolution.

[quantizor]

Fixed in https://github.com/styled-components/styled-components/releases/tag/v6.0.0

[mAAdhaTTah]

Awesome, thank you for the fix! Can confirm the test case is resolved as well.