regexr
regexr copied to clipboard
gskinner
Improve handling of long running regular expressions.
There is a 250 ms limit in place for executing regular expressions. This is to prevent cases where regexp can get into an infinite loop and crash the browser. This however can cause edge cases when parsing large strings.
- To help debug these situations improved error handling would be a bonus. Ex: include a % done, also if the RegExp engine contains an error we can surface it.
- Give control to the end user via a dialog for whether or nor they want to cancel it.
See the comments in #102
@Luminess Thats exactly what we currently do :) The issue is we need to choose some arbitrary point to stop the worker or in some cases it will run forever, and 250ms works for most expressions. Handling those few longer running patterns better would be a nice win.
I think it would be better to instead pause the processing after 250ms, giving the user a small warning notification that it is paused due to timing out with a button to resume processing. That way, it'll give the user more control without being intrusive.
Technically, this is easy. Getting the UI right would be the biggest challenge. I'll aim to take a look at this after v3.0 ships.
When loading a saved regex from a URL, I sometimes get the 250ms error even for very simple and short expressions and inputs like this example: https://regexr.com/5ja86
If I refresh a few times it'll work and report an execution time of 0.1ms instead.
Is the loading time being counted as well?
@vith - interesting. Watching closely, I can see the correct result flicker up briefly, then (probably 250ms later) the error appears. I wonder if we are hitting a race condition where the initial solve is started, then a second solve is immediately triggered due to the query string, and that's leading to the first solve being canceled, but not its error timer.
I'll try to look into this soon.