Page View Background mutates over time

Okay, my head-scratching oddity:

Here’s my page immediately after launch—

Here it is a day later—

Happens consistently when Scrivener is left open for a few hours…

Note: I have not changed anything in preferences. So why the mutation?

All black is the macOS default frame fill, which can sometimes be seen if there is an error in loading an image that is meant to be covering it up. I don’t think the default is to use an image (with a very subtle texture), but it is maybe worth a check.

I’d go into Appearances: Page View: Colors, and under the Background setting, click the colour chip and then use the magnifying glass in the colour palette tool to select from the normal background (or choose your own if you prefer). See if that works better.

If not, then here are two things I would do to increase diagnostic information:

  1. From Finder, use the Go ▸ Utilities menu command and open the program. Set it to warnings and errors in the toolbar, and after those search criteria, add “Scrivener”, to only show warnings and errors that are relevant. Leave that running in the background.
  2. In Scrivener’s General: Warnings preference pane, enable internal error alerts.

Next time it happens, if you get an exception report, paste the result here, and likewise if there are any console messages from around that time.

So, the Pilgrim’s Progress… thus far:

The mutation happened again, going from the default pale grey to pure black. Interestingly, the preference choice/tile became unresponsive. That’s to say, no color choices or clicks would get it to change from black. Tile changes color, not so the background.

Restarting Scrivener yields the default pale gray again.

Meanwhile a filtered Console offers first

[code]Sandbox: java_home(45473) deny file-read-data /usr/libexec
Violation: deny file-read-data /usr/libexec
MetaData: {“build”:“Mac OS X 10.13.3 (17D47)”,“action”:“deny”,“target”:[“usr”,“libexec”],“hardware”:“Mac”,“platform_binary”:“yes”,“profile”:“unknown”,“process”:“java_home”,“op”:“file-read-data”}

Process: java_home [45473]
Path: /usr/libexec/java_home
Load Address: 0x1072c0000
Identifier: java_home
Version: ??? (???)
Code Type: x86_64 (Native)
Parent Process: Scrivener [45465]
Responsible: /Applications/ [45465]
User ID: 501

Date/Time: 2018-02-13 16:55:06.731 PST
OS Version: Mac OS X 10.13.3 (17D47)
Report Version: 8

Thread 0 (id: 15466688):
0 libsystem_kernel.dylib 0x00007fff60adfb82 __open_nocancel + 10
1 CoreFoundation 0x00007fff39016634 _CFIterateDirectory + 84
2 CoreFoundation 0x00007fff39015e26 _CFBundleGetBundleVersionForURL + 534
3 CoreFoundation 0x00007fff39014e46 _CFBundleCreate + 214
4 CoreFoundation 0x00007fff39006da5 CFBundleGetMainBundle + 149
5 CoreFoundation 0x00007fff3904686a CFBundleCreate + 26
6 CoreFoundation 0x00007fff39064661 _CFCopyLocalizedVersionKey + 129
7 CoreFoundation 0x00007fff3906444c _CFCopyVersionDictionary + 172
8 CoreFoundation 0x00007fff3917e488 ___CFCopySystemVersionDictionary_block_invoke + 40
9 libdispatch.dylib 0x00007fff60956d50 _dispatch_client_callout + 8
10 libdispatch.dylib 0x00007fff60956d03 dispatch_once_f + 41
11 CoreFoundation 0x00007fff39064398 _CFCopySystemVersionDictionary + 56
12 JavaLaunching 0x00007fff535f9ba4 MakeMatcher + 70
13 JavaLaunching 0x00007fff535f8723 CreateJVMDetector + 112
14 JavaLaunching 0x00007fff535f82b3 CreateCompleteJVMListSortedByUserPrefsForTask + 108
15 JavaLaunching 0x00007fff535f842a JLCreateJVMListForTaskVersionAndArch + 27
16 java_home 0x00000001072c2587
17 java_home 0x00000001072c1c28
18 libdyld.dylib 0x00007fff60990115 start + 1
19 java_home 0x0000000000000001

Binary Images:
0x1072c0000 - 0x1072c3ff3 java_home (285) <5bb6b513-70a9-3279-8201-ea0a2cf15da4> /usr/libexec/java_home
0x7fff38ff8000 - 0x7fff39498fe7 (6.9 - 1451) <7afe9c8f-a562-3afc-8402-117aa02f57e9> /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation
0x7fff535f7000 - 0x7fff535fbfff JavaLaunching (42) /System/Library/PrivateFrameworks/JavaLaunching.framework/Versions/A/JavaLaunching
0x7fff60955000 - 0x7fff6098eff7 libdispatch.dylib (913.30.4) <7d0e3183-282b-3fee-a734-2c0adc092084> /usr/lib/system/libdispatch.dylib
0x7fff6098f000 - 0x7fff609acff7 libdyld.dylib (519.2.2) /usr/lib/system/libdyld.dylib
0x7fff60ac4000 - 0x7fff60ae9ff7 libsystem_kernel.dylib (4570.41.2) <5155a4c3-825b-3178-ac51-0d2d2f2a6618> /usr/lib/system/libsystem_kernel.dylib
Followed by a repeating litany of many versions of:

error 16:25:14.676768 -0800 Scrivener error: API Misuse: Attempt to serialize store access on non-owning coordinator (PSC = 0x600001669e40, store PSC = 0x0)

Ideas? Recommendations? Names of good single malts?

Hmm, were you compiling around this period of time? The initial console log is an error report, but it’s coming from Java, with Scrivener as the parent—something we would more expect to see if you compiled a word processing file recently. It’s probably entirely unrelated to the visual bug though, we only use Java to run the document converter.

Well, let’s try some very basic troubleshooting steps since the logs don’t seem clear on this, and weird interface issues that nobody else can see are often the result of a slightly botched install or jammed preferences, anyway:

  1. Reinstall the software. Just trash it from Applications and download a fresh copy from either the MAS or our webpage, depending on where you bought it from, and install back into Applications.
  2. If that alone does not suffice, then run through the checklist for resetting preferences.

Hmmm, great minds delete alike. It was going to be my own attack on the problem.

As I use Hazel for housekeeping, trashing the Scrivener 3.0 install also carried with it all the underlying preference files. Shiny, fresh install now up and running. Will monitor behavior over the next few days…

Many thanks.

Note bene: I’m happy to report that the app reinstall and an preferences delete has apparently solved the problem.

You may all go about your business with this bit of wisdom tucked in your cap.