Some CSS hits a pathological case in the rrweb splitCssText pathway causing slowdown in processing

[kevinansfield]

We've just had to disable user session recording on our posthog.com hosted account because our customers started experiencing browser hangs when using our editor with the Grammarly browser extension enabled.

Profiling during the hang showed rrweb's record.js script as the culprit. There's a related issue (rrweb-io/rrweb#1603) on their project but it's been closed.

I've opened the issue here as it affected the posthog project and it may just be a versioning problem with posthog using the v2.0.0-alpha.18 version

[pauldambra]

Hey

rrweb has been on v2 alpha for over 12 months... it's not at all an alpha version just an indication of the amount of time the core contributors have to finish features they want to include in v2

This is a tricky one since if things work normally without grammarly i'm tempted to say it's grammarly bug... but that's not to reject any investigation or fix on our end :)

Can you share anything else about your site / tech stack? I'll need to set up a reproduction so I can investigate - although you're welcome to make a simple app that demonstrates the problem too!

[kevinansfield]

This is specifically a change that occurred in -alpha.18. It's apparently been fixed in rrweb but the -alpha.19 release containing it hasn't been cut yet.

I can only assume reverting to -alpha.17 will fix posthog until the -alpha.19 release is available.

Unfortunately I don't have a minimal repro available right now. Our editor screen where the problem was occurring contained both a textarea and a contenteditable area using Lexical.

[kevinansfield]

FWIW we started getting customer reports yesterday with timing that coincides with your v1.207.1 release that contained the -alpha.18 bump.

[kevinansfield]

One route to a repro would be our editor demo site - https://koenig.ghost.org. We don't have posthog enabled on that and so don't see any problems with Grammarly enabled, but it's a static site that could be cloned and posthog added in order to see the performance issues.

[pauldambra]

#1670

[danLDev]

Have upgraded to the latest posthog version with the fix and we're still experiencing this (for all users, not just grammarly)

[pauldambra]

hey @danLDev

how did you update? the fix hasn't hit the CDN yet so you probably aren't running the fix

[pauldambra]

that has hit the CDN now so hopefully resolved for you

[danLDev]

I just bumped the posthog-js package so I guess you're right. Looks like it's resolved now

[pauldambra]

awesome, thanks for taking time to confirm!

sorry for the interruption

there's a test in the upstream recorder tool to protect against this now, so at least the system as a whole is less fragile now 🙈

[pauldambra]

@kevinansfield I'm going to close this since I've had confirmation from others that it is resolved for them, here and on other channels

obvs feel free to comment back here or contact me over in-app support if you need any follow-up

thanks for the really clear issue and follow-up, helped cut down response time 🙌

[danLDev]

@pauldambra Sorry to do this, I think i may have celebrated too early.

We're still getting reports of page hangs (and in some cases crashes on slower machines), even after bumping posthog-js to the latest version.

[pauldambra]

hey, is the site public for us to take a look? or you can open an in-app support ticket to share details there...

[danLDev]

Unfortunately not, will open a support ticket

[Zloka]

Hi,

We noticed the same in our web application. Disabling session recordings fixed it for now, while we upgrade to the latest PostHog version.

Out of curiosity, do you @danLDev still experience the issue? 🙂

If so, and if it helps @pauldambra with debugging, it should be possible for us to deploy a public-facing site.

[pauldambra]

hey zloka, are you on the latest version? has it improved with the latest versions?

if the site is public I can for sure take a look, i've seen some CSS that is ~10x more expensive to process but I'm not 100% on what's causing it

[pauldambra]

i've reopened this and updated the title since this is definitely not completely fixed but I also don't want folk to think it's completely broken

i've got an improvement to the processing cache on the way to the CDN in 1.209.1 which means folk only take the hit on the first run through the CSS (per page load) but that's obvs still not good enough in the case where the recorder pauses on your css

have asked in the rrweb secret contributors slack too - want to check if someone can ELI5 the purpose of the function to help me figure out the fix (or indeed nerd snipe someone else into fixing it)