P.S. Also, could you please go to Scrivener’s Settings/Preferences, and under General > Warnings, tick “Show internal error alerts”? Then restart the app and get the copyholder bug to trigger again. If it is an error being thrown, this option will make the app tell you the exact error. Please let me know the wording of the error, or show a screenshot of the error, if there is one.
Note that in general you’ll want to keep this option off, because sometimes macOS can throw harmless errors. Also, if Scrivener is throwing an error, don’t do any work after it’s thrown until you’re restarted the app, as an app can be unreliable after an internal error is triggered.
The project was like this in every build when I opened it: Scrivenings in the main editor, locked. Copyholder was already open (bottom position).
When I opened the document in Build 3, it looked like the screenshot above. I tried closing the copyholder and re-opening from the binder and from the menu, and tested all the different positions with no change.
After switching to Build 2 and back to 3 (no two were ever open at the same time), I got an error about the project being open already and made a copy. Now the copyholder is okay in Build 3 in all documents, and I can’t reproduce the error, but I will let you know if it comes up again.
The scrolling in Build 3 seems okay 90% of the time, with the occasional lag or leftover scroll thrown in. I think I need to spend some more time with it to be able to give you anything better than that–will keep updating if I have any more info about the lag or the copyholder error. Thank you so much for your help with this! I’m curious to hear how others get on with this one.
Hmm, strange. Well if you can find a reproduction case of the copyholder breaking again, please let me know. It might not even be related to the scrolling code.
I’m glad scrolling is 90% better, although I’d really like to get it 100% of the way there. I’d be grateful if you could test one more build for me with the scrolling:
Note that in this build, certain button states won’t update correctly, so it’s not one to use for work. In this build, I’ve torn out all the code that I think is involved in the scroll delays. If scrolling works perfectly in this, that confirms it’s the problem. If this only works about the same as build 3, then that tells me that I’ve gone as far as I can with my current approach, and that there must be another factor too. thanks!
I’ve had two projects (both of which exhibit the uncontrollable scrolling issue in Scrivener 3.3.6 and 3.4.0) open in Build 3 since 8:30am yesterday morning (9/19/25). Historically, the problem most often begins anywhere from immediately to a few hours after opening a project. However, 28 hours in with Build 3, and neither project has experienced any scrolling issues yet–neither a lag nor the unstoppable scroll. So far, scroll commands are behaving as perfectly in Build 3 as in Scrivener 3.3.1 (which is the version I’ve used since my earlier post in May 2024, per Frank’s tip, excluding the months I tried version 3.4.0).
I’m not familiar with the copyholder feature, and it didn’t open automatically for me, so I cannot attest to its functionality or lack thereof.
I ran an update from Sequoia 15.4.1 to 15.7 four hours ago, and haven’t observed any changes in performance. Will continue to monitor.
2024 MacBook Pro M4 Max
Sequoia 15.4.1 – 24 hours without issue
Sequoia 15.7 – 4 hours and counting without issue
Build 3 - (…/beta/Scrivener_3_45_UIValidationTest.zip)
I’m going through the code and making a slew of updates based on all of this information, and from feedback based on the test builds. If you (or anyone else encountering the bug) have the time, I’d be very grateful if you could also let me know exactly which build of Scrivener introduced the problem. It seems that 3.3.1 worked fine, but as of 3.3.6 the bug was in place, so it must have been introduced between 3.3.2 and 3.3.6.
Here are download links to Scrivener versions 3.3.2 - 3.3.5. It would be really helpful to know which one the bug first occurs in:
(If it doesn’t occur in any of these, then presumably it started in 3.3.6.)
If I know that, I can go through all of the code changes for the first problematic version to look for extra clues. Although it looks like what I’m doing at the moment is going to address the bug, I want to be as sure as possible. (Unfortunately the bug has stopped reproducing for me now, so I can’t test which build it first appeared in myself.)
I just started having the laggy scrolling bug a few days ago-- so far, build 4 has eliminated it. It’s been a few hours.
I was running scriv 3.5 and had no issues with the lag until a few days ago. My project is huge (>1.3mil) but it’s been huge for years, so I doubt an increase in the word count caused it. None of my other settings changed either.
Argh. I completely rewrote all of the UI validation code in Scrivener 3.5 based on the feedback above that build 4 fixed issues, so I was (wrongly) confident 3.5 had addressed the problem.
Okay, for 3.5.1 I have added another refinement - I’m pausing all UI validation code (which seems to be the issue based on build 4, which tears it all out for testing purposes) during live scroll. 3.5.1 will be out in the next couple of days, so I’d be grateful if you could let me know whether it improves things. If not, we’ll have to try some more test builds (if you don’t mind testing them).
It’s hugely frustrating - this is code that worked for more than fifteen years before Apple made a change to live scrolling that caused all of these issues and requires working around.
Yes, I’m perfectly happy to test 3.5.1 (and other test builds). I’ll wait on the update and try it out. Assume no news is good news-- otherwise I’ll come complain.
I can imagine this problem is aggravating! I appreciate you working to fix it. For what it’s worth, this is the only issue I’ve had in almost a decade of using scriv-- I sincerely appreciate the time and effort you’ve put into it.
I’ve tried it for about 30 minutes now. Had one instance of lag, but nothing since then. I can’t tell if it’s fixed or just more infrequent. I’ll keep trying and let you know if it gets worse again.
Thanks for trying! That one instance of lag isn’t such good news. What happens if you switch back and forth between 3.5 and 3.5.1? Can you reproduce the lag really easily in 3.5 still, where it’s not so easy to reproduce in 3.5.1?
So after using it for maybe 5 more hours, I’ve had one more instance of the lag. It was pretty early on (maybe in the first hour). Haven’t noticed anything since.
Great, thanks for the update. Well at least it’s a lot better even if it’s not perfect. Unfortunately it will be difficult to track the occasional lag since you have to type for a while to see it and it only happens sporadically. I you can find a situation where the lag can always be reproduced, please let me know, as that will be something we can do some tests on.