Summary Safari "WebKit Build Archives" (AKA Safari nighties) crashes when opening Preferences. The Preference window doesn't even pop up before crashing. Steps to reproduce Download a nightly build of Safari https://webkit.org/build-archives/#mac-monterey-x86_64 Open run-webkit-archive Go got Safari > Preferences Observer crash Environment Does crash on: MacBook Pro (15-inch, 2017) macOS 12.2.1 and 12.3.1 WebKit Build Archives (249860@main, 249854@main, 249817@main, 292562) Spot checked a few others from Feb to April as well Do NOT crash on: Safari included with macOS 12.3.1 (Version 15.4 (17613.1.17.1.13)) Safari Technology Preview 143 (Safari 15.4, WebKit 17614.1.7.7) 142 141 Crash stack trace 2022-04-21 13:44:00.485 SafariForWebKitDevelopment[13786:133729] *** Assertion failure in -[NSMenuItem initWithTitle:action:keyEquivalent:], NSMenuItem.m:477 2022-04-21 13:44:00.487 SafariForWebKitDevelopment[13786:133729] *** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'Invalid parameter not satisfying: aString != nil' *** First throw call stack: ( 0 CoreFoundation 0x00007ff8112d81e3 __exceptionPreprocess + 242 1 libobjc.A.dylib 0x00007ff811038c13 objc_exception_throw + 48 2 Foundation 0x00007ff81217ac23 -[NSAssertionHandler handleFailureInMethod:object:file:lineNumber:description:] + 267 3 AppKit 0x00007ff813c74759 -[NSMenuItem initWithTitle:action:keyEquivalent:] + 363 4 Safari 0x00007ff91e63417a +[NSMenuItem(BrowserExtras) safari_menuItemForFileAtPath:] + 140 5 Safari 0x00007ff91e505a0b -[GeneralPreferences _updateDownloadLocationMenu] + 158 6 libdispatch.dylib 0x00007ff810fda0cc _dispatch_call_block_and_release + 12 7 libdispatch.dylib 0x00007ff810fdb317 _dispatch_client_callout + 8 8 libdispatch.dylib 0x00007ff810fe7c78 _dispatch_main_queue_drain + 943 9 libdispatch.dylib 0x00007ff810fe78bb _dispatch_main_queue_callback_4CF + 31 10 CoreFoundation 0x00007ff81129a9c7 __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ + 9 11 CoreFoundation 0x00007ff81125b93f __CFRunLoopRun + 2771 12 CoreFoundation 0x00007ff81125a7ac CFRunLoopRunSpecific + 562 13 HIToolbox 0x00007ff819ee1ce6 RunCurrentEventLoopInMode + 292 14 HIToolbox 0x00007ff819ee1a4a ReceiveNextEventCommon + 594 15 HIToolbox 0x00007ff819ee17e5 _BlockUntilNextEventMatchingListInModeWithFilter + 70 16 AppKit 0x00007ff813c8153d _DPSNextEvent + 927 17 AppKit 0x00007ff813c7fbfa -[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 1394 18 Safari 0x00007ff91e16d8b5 -[BrowserApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 224 19 AppKit 0x00007ff813c722a9 -[NSApplication run] + 586 20 AppKit 0x00007ff813c46227 NSApplicationMain + 817 21 Safari 0x00007ff91e1581c0 SafariMain + 464 22 dyld 0x000000011583e51e start + 462 ) libc++abi: terminating with uncaught exception of type NSException MessageReceiveQueueMap::addImpl - adding duplicate any id receiver 35

"Safari Push Notifications" were not clickable in Safari 16.0. This was reproducible in Safari 16.0 on macOS 12.6. A few Apple customers reproduced and reported this issue already: https://discussions.apple.com/thread/254194011 https://discussions.apple.com/thread/254252152 After Safari 16.1 was released, I was no longer able to reproduce this issue. However Apple did NOT include such a fix in the Safari 16.1 Release Notes. Apple, can you confirm this is now resolved and include this was fixed in the release notes? Other: I only tested Safari's Push Notifications, unknown if this was an issue with "Local Notifications".

One Line Summary Notification.permission is incorrectly reported as "default" on iOS App Webs, this happens when tapping on a notification that results in a new "window" being opened via clients.openWindow. Why this is is important to fix This is confusing to the end-user as sites will check Notification.permission and see it is "default" and then attempt to show the end-user a soft notification permission prompt again. Steps to reproduce the issue On a iOS 16.4 or newer device open https://ios-webapp-notification-new-window-permission-bug.glitch.me in Safari Tap share button Tap "Add to Home Screen" Open the iOS Web App you just added Tap "Prompt Notification permission" On the iOS native notification permission prompt press "Allow" Tap "Display notification" Tap on the notification [Safari/iOS Bug] Observe Notification.permission reports as "default" when it should be "granted" What devices are affected I have reproduce this issue on an iPhone 14 Pro on both iOS 16.7.2 & 17.1.2. However I would expect all iOS 16.4+ devices to be effected.

One Line Summary window.safari.pushNotification.requestPermission() is no longer showing a prompt to the user with Safari 17.3 on macOS 14.3 and it's callback fires as "denied". Why this is is important to fix Starting with Safari 16 for macOS 13 Apple introduced support for the standard Push API. However it is expected that the original Safari JS API window.safari.pushNotification should continue working, as many sites have not fully upgraded to the new API and Apple has not announced a deprecation. Environments NOT Working macOS 14.3 with Safari Version 17.3 (19617.2.4.11.8) macOS 14.4 Beta (23E5191e) with Safari Version 17.4 (19618.1.13.11.5) Working macOS 13.6.4 with Safari Version 17.3 (18617.2.4.11.11, 18617) MRE (minimal reproducible example) See the following site to quickly reproduce the issue noted here: https://public-mre-macos-window-safari-prompt-bug.glitch.me/