webkitLineRegex can lock the page up on certain errors

[elee1766]

We noticed that some users pages would "randomly" freeze after certain actions, but it would be sparingly, and inconsistent

we were able to eventually get a reproduction on chrome, showing a big trace block where one thing was running and hanging the entire page

this i was able to trace back to https://github.com/grafana/faro-web-sdk/blob/main/packages/web-sdk/src/instrumentations/errors/stackFrames/const.ts

I don't really know what sort of conditions that are causing this, nor do i have the error that is causing this, sorry that this post is not more informational or convincing, but I thought I would post in case other people are having issues with their pages intermittently freezing after sending errors to faro, who can maybe provide some more information

i suspect it is some combination of errors from extensions or other packages that end up causing the regex to perform badly

[eskirk]

hey @elee1766 thanks for the valuable report. I have seen something similar with regexes of this complexity - I think we will need to take another look at these expressions and see how we can simplify them. with a long enough line of a stack trace, the runtime could definitely behave like this.

[elee1766]

thank you. i will try to figure out how to get some possible blobs that reproduce.

in the mean time @eskirk what would be the easiest way using the web+react sdk to disable stack trace parsing so peoples pages stop freezing?

[eskirk]

@elee1766 a temporary workaround to avoid any stack trace parsing would be to remove the ErrorsInstrumentation from your Faro config.

if you are using getWebInstrumentations in your Faro config, that is a shorthand for including the following instrumentations:

[
    new ErrorsInstrumentation(),
    new WebVitalsInstrumentation(),
    new SessionInstrumentation(),
    new ViewInstrumentation(),
];

you could replace getWebInstrumentations with the subset of instrumentation you wanted to keep enabled until we fix this issue.

hopefully this explanation makes sense and works for you in the short term.

[elee1766]

@elee1766 a temporary workaround to avoid any stack trace parsing would be to remove the ErrorsInstrumentation from your Faro config.

if you are using getWebInstrumentations in your Faro config, that is a shorthand for including the following instrumentations:

[
new ErrorsInstrumentation(),
new WebVitalsInstrumentation(),
new SessionInstrumentation(),
new ViewInstrumentation(),
];

you could replace getWebInstrumentations with the subset of instrumentation you wanted to keep enabled until we fix this issue.

hopefully this explanation makes sense and works for you in the short term.

thank you, we will do this.

I have also found a example of a string which performs very badly in stack trace parsing. I believe it's coming from metamask:

https://gist.github.com/elee1766/ed79c091c510ab1d4373227534432d27

the first is the full stack string

the second is a profile analysis of the script im running below with tsx --prof

the third is the snippet im putting at the bottom of getStackFramesFromError.ts to generate said profile.

it takes a good amount of time even outside of the browser