When I quit Scrivener on macOS (Sequoia) and then launch Activity Monitor, I find 7 processes running from Scrivener titled, ‘about:’ each consuming 53 to 55 MB of Ram, plus a ‘ScrivQuickLook (Finder)’ process consuming 29 MB of Ram, so about 400MB of RAM occupied - after I quit Scrivener, when the program is not even running.
Is there any setting that would stop this, short of logging out and back in, and not launching Scrivener?
I am unable to reproduce this (on Sequoia). The only processes in evidence are the Scrivener app process itself, and a persistent process ScrivThumbnail (7.8mb).
What I did:
That’s what I get when Scrivener is running:
(Otherwise nothing, before or after.)
Scrivener 3.5.2 on macOS 15.7.7
I looked into this a while back, and here are my notes from then:
Long story short, we give the system a tool to preview your Scrivener project without opening Scrivener, it uses that tool, and then trips all over itself. There isn’t much we can do about that, unfortunately.
It took me a bit to see it happen, as I could not spawn these “about:” processes when using any of the mechanisms I ordinarily would use to load projects or Scrivener (LaunchBar), or from recent/favourite project mechanisms. It was only after I went into Finder and double-clicked on a project that one popped up. Even then it did not seem to always happen (definitely more reliable when actually using Quick Look).
I examined the process in Activity Monitor, and found it comes from this framework:
/System/Library/Frameworks/WebKit.framework/Versions/A/XPCServices/com.apple.WebKit.WebContent.xpc/Contents/MacOS/com.apple.WebKit.WebContent.
That makes sense, as the Quick Look data for the project would involve spawning a WebKit process, it being HTML-based.
It would also explain why quitting Scrivener does not get rid of them. They are not child process of Scrivener, but rather the process used to load the file itself (launchd), and created at the behest of extensions for Quick Look and Finder thumbnail previews that Scrivener installs and provides, but does not directly execute or use in any fashion itself.
Presumably if you forced Finder to restart it might clear some of them, but in my testing it did not seem as reliable as using Activity Monitor to clear them out, or regularly reboot/log out. You can’t force quit launchd, and if you even could it would immediately halt the entire system because that is the root process for everything other than the kernel itself.
This problem persists in macOS 26.5 (although it might be a bit better about not spawning them from simple double-clicks).
To all, thanks for the efforts.
I too could not reproduce the behavior. I logged back in and found only 4 of the about: in Activity Monitor; Force Quit - Relaunch Finder cleared them all out for me, and since then I have not found any. That pesky ‘launchd’ daemon is hated but needed in macOS if I recall aright; or was that Linux that dropped it and had to bring it back?
RAM usage on the mac is ‘smart’ in that way that Apple likes, opaque and mysterious and sometimes it works out and sometimes not, and we mortals just have to grin and bear it.
Anyhow thanks again, and back to work for me–
Probably systemd on Linux. I’m not aware of widespread disdain regarding launchd.