Post not yet marked as solved
Starting in Monterey 12.1 (Intel), our custom 3rd party screen saver is occasionally failing to work properly when in the Preview mode (e.g. the small sample window inside the Desktop & Screen Saver system preferences window).
If I turn on detailed logging, I see the following calls being made:
ScreenSaverView.Init ScreenSaverView.hasConfigureSheet ScreenSaverView.draw
However,
ScreenSaverView.StartAnimation ScreenSaverView.AnimateOneFrame
are never called
Oddly, this only happens when first opening the Desktop & Screen Saver window.
Because, if you:
start the screensaver (using the Preview button or a Hot Corner) then exit the screensaver
open the Screen Saver Options panel for this screensver then close it
switch to another screensaver then back...
Any of these actions will cause the screensaver preview to start working.
This sounds a little bit like what's beeing seen in https://github.com/JohnCoates/Aerial/issues/1190 which is a different 3rd party screensaver.
Post not yet marked as solved
Starting with Catalina Developer Beta 5, third-party screensavers are no longer able to receive and respond to keyboard and mouse events. Many third-party screensavers make use of this feature. The new behavior is clearly wrong - documentation for ScreenSaverView says that it is a NSView subclass, and thus we should be able to override keyboard and mouse events.Submitted as FB6916019
Post not yet marked as solved
What's the best way to submit 10.13 bugs? Anyone had better luck using bugreport.apple.com vs. Feedback Assistant?
Post not yet marked as solved
Warning: It appears that Security Update 2020-005 is causing trouble with Screen Savers which are built using the Swift Runtime.
Symptoms: after updating to Security Update 2020-005 on macOS 10.14 Mojave: Swift-built screensavers no longer funcion
You will get a blank screen when the screensaver activates the first time.
After the first time, the screensaver will revert to the default macOS screensaver
Attempts to view the screensaver in System Preferences / Desktop & Screen Saver will give a blank page
Crash logs indicate that the com.apple.preference.desktopscreeneffect.screeneffects.remoteservice process is crashing (see typical crash log below)
Regression Testing: This happens on macOS 10.14.6 with Security Update 2020-005. We do not know if it affects other versions of macOS
This affects personal or commercial screensavers built using iScreensaver ( iScreensaver.com ) but also seems to affect other screensavers such as the swift Clock.Saver found here: https://github.com/soffes/Clock.saver
Typical Crash Log:
Process:							 com.apple.preference.desktopscreeneffect.screeneffects.remoteservice [962]
Path:									/System/Library/PreferencePanes/DesktopScreenEffectsPref.prefPane/Contents/Resources/ScreenEffects.prefPane/Contents/XPCServices/com.apple.preference.desktopscreeneffect.screeneffects.remoteservice.xpc/Contents/MacOS/com.apple.preference.desktopscreeneffect.screeneffects.remoteservice
Identifier:						com.apple.preference.desktopscreeneffect.screeneffects.remoteservice
Version:							 1.0 (1)
Build Info:						DesktopScreenEffectsPref-229003000000000~20
Code Type:						 X86-64 (Native)
Parent Process:				??? [1]
Responsible:					 System Preferences [955]
User ID:							 507
Date/Time:						 2020-09-26 08:19:16.779 -0700
OS Version:						Mac OS X 10.14.6 (18G6032)
Report Version:				12
Anonymous UUID:				DA9B5F71-78EB-7DD2-F219-AF6A3A811FC1
Time Awake Since Boot: 1300 seconds
System Integrity Protection: enabled
Crashed Thread:				0	Dispatch queue: com.apple.main-thread
Exception Type:				EXC_BAD_ACCESS (SIGSEGV)
Exception Codes:			 KERN_PROTECTION_FAILURE at 0x00007ffeef184ff8
Exception Note:				EXC_CORPSE_NOTIFY
Termination Signal:		Segmentation fault: 11
Termination Reason:		Namespace SIGNAL, Code 0xb
Terminating Process:	 exc handler [962]
VM Regions Near 0x7ffeef184ff8:
		MALLOC_SMALL					 00007fc640000000-00007fc640800000 [ 8192K] rw-/rwx SM=PRV	-> STACK GUARD						00007ffeeb985000-00007ffeef185000 [ 56.0M] ---/rwx SM=NUL	stack guard for thread 0
		Stack									00007ffeef185000-00007ffeef985000 [ 8192K] rw-/rwx SM=SHM	thread 0
Application Specific Signatures:
Clock
Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0	 libsystem_malloc.dylib				 0x00007fff79a0fc95 malloc_zone_malloc + 99
1	 libsystem_malloc.dylib				 0x00007fff79a0fc99 malloc_zone_malloc + 103
2	 libsystem_malloc.dylib				 0x00007fff79a0fc99 malloc_zone_malloc + 103
3	 libsystem_malloc.dylib				 0x00007fff79a0fc99 malloc_zone_malloc + 103
4	 libsystem_malloc.dylib				 0x00007fff79a0fc99 malloc_zone_malloc + 103
[... this stack trace repeats for 511 entries ...]
Post not yet marked as solved
This fails for me in Big Sur:
open System/Library/PreferencePanes/DesktopScreenEffectsPref.prefPane
The pane opens, but the list of screensavers is blank.
Has anyone found a way to work around this?
I've submitted this issue as FB8044776
My Mid 2013 MacBook Air should be compatible with Big Sur, I believe.
I've loaded the Developer Beta Access utility, after which I see "macOS Beta" on the Software Update panel. I click Upgrade Now. It downloads 9.56GB of files, and then afterwards shows a generic error message. I've tried this 3 times now.
Possible issues with my macbook air? it has an external USB ethernet dongle.
it has an external monitor
it's set up with BootCamp running Windows 10
It has 33.25GB of free drive space.
It was already running 10.15.6 beta 2.
Any ideas?
Post not yet marked as solved
According to https://www.macrumors.com/2020/02/05/apple-seeds-macos-catalina-10-15-4-beta-1/we should be seeing the first beta of 10.15.4, but when I check Software Update I'm stuck on 10.15.3 (and it says "This mac is enrolled in the Apple Beta Software Program..."Anyone else seeing it?
Post not yet marked as solved
I have a .saver which attempts to launch a helper .app and the helper app is struggling under Catalina (beta 1-3).The .saver is launching the .app using a simple call to Process.LaunchThe errors look like this:rejecting read of { com.mycompany.saver.77300306, kCFPreferencesAnyUser, kCFPreferencesCurrentHost, no container, managed: 0 } from process 1281 (myScreensaver) because accessing preferences outside an application's container requiresuser-preference-read or file-read-data sandbox accessWhat's interesting:the error happens in my app before I do any reading or writing of CFPreferences - it appears to be the Appkit framework itselfthe CFPreferences are being read from kCFPreferencesAnyUser, kCFPreferencesCurrentHost, which seems wrong - shouldn't it be CurrentUser? I would expect that a sandboxed process would have no permissions to write to the AnyUser domain.also, when the app launches, it opens a WKWebView, which fails to render properly.What I've tried:I've tried adding / removing changing the plist for my helper app (sandbox, sandbox inherit, various entitlements) but nothing seems to have any effect.I've found a partial workaround, which is to set the CFBundleIdentifier to the path to the container, e.g. /Users/username/Library/Containers/com.apple.ScreenSaver.Engine.legacyScreenSaver/Data/Library/Preferences/com.mycompany.saver.77300306 This prevents all the error messages in console; however WKWebView still fails to load.
Post not yet marked as solved
Try doing a search on the main forum page, e.g. from herehttps://forums.developer.apple.com/community/beta/macos-1015-betasearch for "legacyScreenSaver"Result: works.Now try the search from here:https://forums.developer.apple.com/community/beta/macos-1015-beta/contentResult: nothing is found.This is broken, right? I thought my post had been deleted at first.
Post not yet marked as solved
I'm having lots of trouble with screen savers in the first 10.15 beta. Console is showing messages from a new "legacyScreenSaver" process. The ScreenSaver API doesn't show any documented changes, however.https://developer.apple.com/documentation/screensaver?changes=latest_minorAnyone else seeing this?In particular, I'm having trouble with a Swfit-based screensaver.One example:ScreenSaver.init(frame:isPreview:) is being called with isPreview=True, even when running normally fullscreen.