[Bug]: css capture that doesn't display in all browsers

[pauldambra]

Preflight Checklist

• I have searched the issue tracker for a bug report that matches the one I want to file, without success.

What package is this bug report for?

rrweb

Version

2.0.0-alpha.4

Expected Behavior

That captured CSS should display the same when applied to an element in a browser as it did when captured from it

Actual Behavior

A customer of ours (PostHog) is using some CSS to make titles on their page pretty

You can see the setup in this jsfiddle https://jsfiddle.net/pauldambra/k4rqm593/41/

In safari and firefox the CSS as captured by rrweb displays correctly when applied to an element in the fiddle. But in Chrome the captured CSS causes the text to appear to be invisible.

I'm not certain this is a bug in rrweb to be honest. But would be great to get advice on if there's a workaround we can apply or suggest to the customer if not.

In the fiddle you can see that the CSS that is applied is

  background: linear-gradient(127.44deg, #C63A3A 32.29%, #3A2828 100%);
  -webkit-background-clip: text;
  -webkit-text-fill-color: transparent;
  background-clip: text;
  text-fill-color: transparent;

rrweb captures that as

  background: linear-gradient(127.44deg, rgb(198, 58, 58) 32.29%, rgb(58, 40, 40) 100%) text;
  -webkit-text-fill-color: transparent;

That captured CSS works in Safari and Firefox but not in Chrome

Steps to Reproduce

see https://jsfiddle.net/pauldambra/k4rqm593/41/

Testcase Gist URL

No response

Additional Information

No response

[Juice10]

Do you know what browser was used to capture this?

[eoghanmurray]

As OP mentioned, the jsfiddle works fine in browsers apart from Chrome, so it is a Chrome bug.

For the example of the inline <style>, the problem is in snapshot.ts where this happens:

if ((n.parentNode as HTMLStyleElement).sheet?.cssRules) {
        textContent = stringifyStyleSheet(
          (n.parentNode as HTMLStyleElement).sheet!,
        );
 }

The textContent is correct:

> textContent
'\n    #deleteme-h1 {\n  background: linear-gradient(127.44deg, #C63A3A 32.29%, #3A2828 100%);\n  -webkit-background-clip: text;\n  -webkit-text-fill-color: transparent;\n  background-clip: text;\n  text-fill-color: transparent;\n}\n    /* EOS */\n  '

but when examined via the cssRules of the parent stylesheet we get the following

#deleteme-h1 { background: linear-gradient(127.44deg, rgb(198, 58, 58) 32.29%, rgb(58, 40, 40) 100%) text; -webkit-text-fill-color: transparent; }

(we need to look at cssRules as the style element might have been updated programmatically with new rules which would not be reflected in the textContent)

The information is still there in the following:

> rule.style['webkitBackgroundClip']
'text'
> rule.style.webkitTextFillColor
'transparent'

However it would need some hacking to work around.

There is a fixBrowserCompatibilityIssuesInCSS function where you could implement fixes. First step I think would be to get rid of the older stringifyStyleSheet function and replace the single call to that function with a call to getCssRulesString which is newer and runs things through fixBrowserCompatibilityIssuesInCSS.

However that 'fix' function would likely want to compare with the 'raw' textContent which it doesn't currently do (I'm not sure whether the raw text content is available in all contexts).

I'll look for a Chrome bug on this to see if it is all worth it.

[eoghanmurray]

Lots of issues here:
https://bugs.chromium.org/p/chromium/issues/list?q=webkit-background-clip&can=2

nothing much here:
https://bugs.chromium.org/p/chromium/issues/list?q=-webkit-background-clip%20cssrules&can=2

Hopefully you have enough to go on to think about a fix if you are motivated to provide one!