If a PDF is displayed in the editor and I type words quickly in the search field at the same time, perhaps delete one and then continue typing, Scrivener (always) freezes. The ram demand then starts to increase continuously and there is no other option but to force quit Scrivener.
This only happens if a PDF is displayed during the search. The size of the PDF does not matter.
Has anyone had this experience?
Hi.
You should specify Mac/Windows
Ah, sorry, Mac.
The workaround is of course not to have a PDF in the editor while searching. But sometimes I forget that.
Can anyone reproduce this? Maybe it’s the same with Windows.
Thanks, I can confirm this bug. In smaller tests the memory will spike and the software will freeze up a bit while changing the content of the search field, but once it sorts itself out, the memory is released and responsiveness returns. In larger projects that spike may take so long, and consume so much memory that recovery isn’t possible or practical.
It probably has to do with continually scanning the PDF text for search matches so that they can be highlighted, since that is something done visually and in “real time” as you type, so long as a PDF is in view.
I would like to repeat my question.
Will this bug be fixed? Yes, no, maybe?
Maybe? 
That it is now a known problem is all I could say then or now, otherwise I would have said more. I don’t even know if it can be fixed. It could be a bug in the PDFKit viewer that is impossible to get at, for all I know.
Friendly reminder. This bug is driving me crazy. It would be great if it was fixed with Scrivener 4 … even better before 
Funnily enough I was just looking at that one the other day, to make sure it is still a problem on macOS 14.
Otherwise, I would suggest you look at the change log page, and hunt for a pattern in when maintenance updates tend to initially occur, vs when you reported this. 
