Bug: freezes tab when editing regex

[ghost]

When using Chrome/Internet Explorer, if I paste the following regex into the expression box: /{{(\s_[^\s{}]\s_)*}}/g

When deleting the first two curly braces, it immediately locks up the page, rendering it completely unresponsive. Can't click on anything, type, etc...

I would imagine this is because it somehow entered an infinite looping state.

Oddly enough, this happens only when on a freshly opened Regexr page, with the default test strings in place. I haven't been able to recreate this issue when the test strings are modified.

Hope this helps solve whatever the underlying issue is. For what it's worth, I absolutely love this tool and hope you continue the good work on it.

[gskinner]

That pattern results in an exponential growth for the search cost. That is, every additional character in the Text costs exponentially more than the one before it to run the search.

Safari and Firefox limit the maximum search time, but Chrome and IE do not. For me, about 90 characters is where it becomes noticeably slow, and by the time you hit 100 it's crashing. This only seems to happen if there are spaces in the string.

Unfortunately, regex execution is a black box, so we can't really handle this case. Feel free to report it to the Chrome and IE teams, and hopefully they will address it in future builds.

It might be possible to push it to a worker, and then terminate it if it takes too long. I'm not sure whether termination would work with a runaway internal process. Worth looking into, particularly if we add support for asynchronous results in preparation for supporting other flavours.

I'll leave this open for now.

[ghost]

Thanks for the quick and detailed reply.

[gskinner]

As an update to this, we just merged in a fix that uses Workers. We're still tweaking the related UI, but it should push live in the next week or so.

[ghost]

That was quick thanks for the update. Will try it out soon.

[gskinner]

This update just went live. Thanks again for the report.