Open fbennett opened 6 years ago
Thanks for proposing a fix for this. I also see you found the issue with the investigation into what is happening.
Out of interest, do the documents you are indexing contain unicode characters?
As for your change, this may work but I'd also like to understand what, if any, impact it has on performance. I still think that having a smarter trimmer is the right eventual fix, finding time to implement that is tricky for me at the moment though.
In a tool that uses lunr.js client-side, and performs searches with a fuzzy query (literal, trailing wildcard, editDistance of 1), lunr.js was crashing (erratically) on iOS browsers with:
Digging further, we found that the strings in
expandedTerms
were somehow being corrupted. Skipping the corrupted items got the system working, but (of course) search results differed on iOS and Linux (we didn't test Windows). Cloning theclause
object as in this pull request gets us identical results on the two platforms.Not sure what's going on there. Maybe the JS engine in iOS does some sort of optimization on objects in a loop.