FYI, we just tested beta 5 (25A5327h) and aren't seeing any improvements or changes.

I have also submitted a case regarding the regressions in UI/UX for screensavers: Tahoe has redesigned the UI for System Settings to remove the Screen Saver pane altogether. Instead, you access Screen Savers from within the Wallpaper settings. This has the following issues: Confusion - macOS has emphasized the importance of Screen Saves in recent years, and users expect to have a Screen Saver pane Usability - although you can access the Screen Savers settings, it’s now hidden behind a button within the Wallpaper settings, and the resulting window runs as a very small modal non-resizable dialog. Since macOS ships with dozens of screensavers by default, forcing the user to navigate these in a tiny window is just silly. Backwards compatibility is broken. For example, the command open x-apple.systempreferences:com.apple.ScreenSaver-Settings.extension No longer works in Tahoe. FB18698083

Testing using Beta 3, I've figured out one of the issues: In macOS Tahoe, when you are viewing the Screen Savers dialog (from inside Wallpaper), using legacyScreenSaver, the system is incorrectly launching 2 copies - one at fullscreen on the main screen, and then a second (correct) instance which is in Preview mode. Reported as FB18697726

Another issue: WKWebView-based screensaver doesn't display on 2nd monitor (legacyScreenSaver) in Tahoe Submitted as # FB17938870

Yes, the CSS has :hover classes, for example: .PlayPauseButton:hover { color: #FF0; text-decoration: none; cursor: pointer; } When i run this HTML/CSS in Safari, or in a normal WKWebView in a test app, it all works normally.

It's not related to NSAppleEventsUsageDescription - that's for something else. Specifically, I'm trying to set up a CGEventTap with the defaultTap option: https://developer.apple.com/documentation/coregraphics/cgeventtapoptions/defaulttap This triggers the OS dialog that looks like this: My question is: can this dialog be customized in any way?

There are many bugs with third-party screensavers under Sonoma. Here's a long thread that discusses a number of fixes: https://github.com/JohnCoates/Aerial/issues/1305 In particular, if your screensaver detects when it needs to exit, it can call exit(0) which seems to do the trick. Direct link: https://github.com/JohnCoates/Aerial/issues/1305#issuecomment-1680853387

Please take a look at https://forum.iscreensaver.com/t/understanding-the-macos-sonoma-screensaver-plist/718

I'm digging into this in more depth, don't have specific answers to all the issue yet, but am discovering some workarounds, and will post back when I have things sorted out. Feel free to contact me directly if you want info sooner - I'm active in a few places, including https://github.com/JohnCoates/Aerial/issues

@eskimo We are also getting reports of failures in first-party Apple screensavers using 13.4 on multi-monitor systems - in particular the Shifting Tiles screensaver has random blank screens when starting on 2 or 3 monitor systems. Shifting Tiles: when using the "Options / Source: Colors" (which doesn't use photos, just blocks of color) it seems to work fine on 2 or 3 monitor systems. However, if I choose "Options / Choose Folder" or "Options / Photos Library" then I can see some sort of malfunction: With 2 monitors: after the screensaver starts, I get 2 blank screens for about 20 seconds. After 20+ seconds, then both screens start working. With 3 monitors: after the screensaver starts, I get 5 seconds of blank screen, then monitor 1 starts, then another 5 seconds, monitor 2 starts, then another 5 seconds and monitor 3 starts. With repeated testing, the pattern is somewhat random: sometimes 1 and 2 start right away, followed by 3 about 5 seconds later.

Unfortunately this bug has been improved, but not fixed. In 13.4 RC, a system with 2 monitors works about 95% of the time. On a system with 3+ screens, the failure rate is 100%. Submitted a new FB case FB12179420 Discussion continues here: https://github.com/JohnCoates/Aerial/issues/1286

Thanks @eskimo the FB cases we know about are FB12023530 and FB12007471 - the thread which has the most technical details is this one: https://github.com/JohnCoates/Aerial/issues/1286 Note that the bug appears to be random and intermittent, so one successful test doesn't mean it's not happening. Test multiple times.

Still happening in Beta 3 - I've narrowed it down a bit, it appears that any use of WkWebView in a x64 Intel app no longer functions on M1 / ARM macs: Instead, the WebKit process crashes. A standalone ARM build, or a Universal Intel/Arm build work fine. Apple: this is a very bad regression, any insight? I have updated FB11786440 with an XCode sample project to illustrate the crash.

I am no longer seeing this issue in the first beta of macOS 13 Ventura (22a5266r)

This bug is still present in 12.2 release version (Silicon and Intel).