Using '&::placeholder' selector throws error on Chrome

[gregjacobs]

Current behavior:

When using the '&::placeholder' selector on Chrome with the sheet in "speedy" mode (i.e. using the insertRule() API), Chrome throws errors that it can't insert the ::-moz-placeholder and ::-ms-input-placeholder rules.

Looks to also be an issue on Safari

To reproduce:

Enable "speedy" mode (or just build for production), and use a '&::placeholder' selector.

Reproduction in codesandbox: https://codesandbox.io/s/emotion-forked-d29s1?file=/index.js

Expected behavior:

It seems that Chrome is just not going to be happy with the auto-prefixing behavior when using the insertRule() API. May need to do some basic browser detection to not insert the ::-moz-placeholder and ::-ms-input-placeholder rules when on Chrome/Safari.

It's possible that this is an issue in other browsers as well.

Environment information:

• @emotion/css version: 11.0.0
• Chrome: 87
• Safari 13.1

[Andarist]

It ain't nothing new but apparently, you are the first one to notice that 😅 I guess it's because setting speedy in dev is rather rare.

I've done some quick checks and it seems that other selectors are affected as well:

• :-moz-read-write
• :-moz-read-only

One thing that those have in common is that those are targeting pseudo-classes/pseudo-elements. So probably this could happen with more but I'm not aware of any other such selectors that could throw on Chrome/Safari.

As we are swallowing insertion errors in production anyway I believe that it would be best to just do the same in dev for those selectors. It wouldn't introduce any new runtime code/checks but also wouldn't trip anyone by being visible in the console as errors. Thoughts?

[gregjacobs]

Hey @Andarist. Ah very interesting that other selectors are affected as well - does make sense!

So the reason this is an issue for us is because we're a library which uses Emotion behind the scenes, but the apps that consume us have console error monitoring and other error logging that happens (local disk logging when the app is deployed into a desktop container, and also error logging that goes over the network). These errors will fill up logs and sound alarm bells and such.

Any thoughts on how to fix? One thought that comes to mind from our end is to intercept the calls to Emotion and replace ::placeholder with the browser-specific prefixed version, but that would definitely not be ideal. Seems like a fix belongs in Emotion itself. I haven't gone through the code yet but is this something that Emotion is doing or Stylis?

[Andarist]

Stylis is „just” a parser (a very cool one!). It only gets strings as an input and gives us back a string (well, actually it outputs an array of AST nodes which are immediately dumped into a string using its plugins and stringifier) - its pure. We take care of the actual insertion etc.

It seems it wasnt clear so let me rephrase - i think it would be best if we just stop logging those particular errors in @emotion/sheet. We already dont log any errors in production there so it doesnt sound like a big problem to filter out some insertion errors in dev as well.

[gregjacobs]

Hmm, I'm not sure if that's the best option to suppress all insertion errors because if we do in fact insert rules that are invalid, we'll want to know about them. Or, are you saying that maybe we could just suppress insertion errors from non-recognized browser prefixes?

Believe it or not, we actually work with Emotion's sheet in "speedy" mode while building our library so we can get a general idea about runtime performance while we're working. We work on some large and complex components and when we have animations while inserting new style rules, we want to make sure we're generally hitting that 60fps. Hence, it would be best if we could still see any errors from bad rule insertions in speedy mode.

It sounds like Stylis is providing the browser prefixes before Emotion inserts them. From the sound of that, it doesn't seem like we get the chance to modify the AST before Stylis returns the new stringified version to Emotion? Or, is there a plugin that could be used with Stylis to filter them out?

One last option I can think of is to ask the Stylis author(s) to not generate the prefixes for browsers that don't apply when it's executed within a browser environment. I could raise an issue with them if you think that would be best?

[Andarist]

Or, are you saying that maybe we could just suppress insertion errors from non-recognized browser prefixes?

This.

It sounds like Stylis is providing the browser prefixes before Emotion inserts them. From the sound of that, it doesn't seem like we get the chance to modify the AST before Stylis returns the new stringified version to Emotion? Or, is there a plugin that could be used with Stylis to filter them out?

It would be possible to create such a plugin but I kinda doubt that it's worth the trouble (using @emotion/css/create-instance or @emotion/react is also a requirement for this). Such a plugin would also not work well with SSR.

One last option I can think of is to ask the Stylis author(s) to not generate the prefixes for browsers that don't apply when it's executed within a browser environment. I could raise an issue with them if you think that would be best?

This is rather out of Stylis scope.

---

I'll be working on swallowing those particular invalid insertions 🔜

[gregjacobs]

Cool, kk, sounds good to me! Thanks man!

[gregjacobs]

Hey, thanks for fixing @Andarist!