When using password autofill on Safari 17.1 (Sonoma 14.1 on M1 Mac), and a third party password manager, the quicktype bar doesn't appear. However on an Intel Mac with the same version of Sonoma and same Autofill configuration, it works as seen on Ventura. Feedback assistant report has been submitted (FB13333122).

When using password autofill on Safari 16.4 (Ventura 13.3 on M1 Mac), and a third party password manager, when the proposed credential is selected an exception dialog appears. This is new behaviour since the 16.4/13.3 update. Touch id may be on or off - same result. Traceback from exception: Exception Name: NSInvalidArgumentException Description: -[WBSCredentialIdentityMatch autoFillPasskey]: unrecognized selector sent to instance 0x600003bd3f00 User Info: (null) 0 CoreFoundation 0x000000018928719c __exceptionPreprocess + 176 1 libobjc.A.dylib 0x0000000188da64d4 objc_exception_throw + 60 2 CoreFoundation 0x000000018932e178 -[NSObject(NSObject) __retain_OA] + 0 3 CoreFoundation 0x00000001891ef150 ___forwarding___ + 1600 4 CoreFoundation 0x00000001891eea50 _CF_forwarding_prep_0 + 96 5 Safari 0x00000001b3ffc7b4 -[FormAutoFillCompletionControllerObjCAdapter shouldShowAuthenticationSheetForCompletionListItem:] + 136 6 Safari 0x00000001b3ffa770 -[FormAutoFillCompletionControllerObjCAdapter performActionForListItem:result:shouldAbortCompletion:] + 44 7 Safari 0x00000001b3ff04e8 _ZN6Safari32FormAutoFillCompletionController29performSelectedListItemActionERNS_33FormAutoFillCompletionShouldAbortE + 84 8 Safari 0x00000001b3ffb844 -[FormAutoFillCompletionControllerObjCAdapter menuTableView:mouseUpInRow:] + 56 9 Safari 0x00000001b3f0dbe0 -[MenuTableView mouseDown:] + 312 10 AppKit 0x000000018c5ce474 -[NSWindow(NSEventRouting) _handleMouseDownEvent:isDelayedEvent:] + 3476 11 AppKit 0x000000018c5590dc -[NSWindow(NSEventRouting) _reallySendEvent:isDelayedEvent:] + 364 12 AppKit 0x000000018c558d9c -[NSWindow(NSEventRouting) sendEvent:] + 284 13 AppKit 0x000000018c5580e0 -[NSApplication(NSEvent) sendEvent:] + 1556 14 Safari 0x00000001b3dc6f64 -[BrowserApplication sendEvent:] + 496 15 AppKit 0x000000018c7a80f0 -[NSApplication _handleEvent:] + 60 16 AppKit 0x000000018c41f57c -[NSApplication run] + 500 17 AppKit 0x000000018c3f69a8 NSApplicationMain + 880 18 Safari 0x00000001b412daa8 SafariMain + 408 19 dyld 0x0000000188dd7f28 start + 2236

Testing an iOS app using iCloud Drive on iOS16.1, iOS15.5 and iOS14.5 - these all work fine on Intel (Monterey or Ventura) but not on an M1 Mac running Monterey. The iOS16.1 simulator throws an exception with bird, which could have some bearing on it - but this isn't seen with the other simulators, and none of them sync iCloud Drive after leaving it running for over an hour (and manually triggering iCloud Sync). Has anyone else this problem? How about on Ventura on an M1?

Normally iCloud documents can be opened when off-line. However, with ios 13, if you have an active SMB server connection in the Files App, and then the network is disabled, calls to UIDocument initWithFileURL: block indefinitely while attempting to lookup file attributes.Note calls to [UIDocument openWithCompletionHandler:], [NSURL getResourceValue:forKey:error:] and ExternalProviderPrepareValues.Backtrace:Thread 1 name: Dispatch queue: UIDocument File Access Thread 1: 0 libsystem_kernel.dylib 0x00000001b493a784 mach_msg_trap + 8 1 libsystem_kernel.dylib 0x00000001b4939ba8 mach_msg + 76 2 libdispatch.dylib 0x00000001b482bf10 _dispatch_mach_send_and_wait_for_reply + 552 3 libdispatch.dylib 0x00000001b482c304 dispatch_mach_send_with_result_and_wait_for_reply + 56 4 libxpc.dylib 0x00000001b476b96c xpc_connection_send_message_with_reply_sync + 240 5 Foundation 0x00000001b507a398 __NSXPCCONNECTION_IS_WAITING_FOR_A_SYNCHRONOUS_REPLY__ + 16 6 Foundation 0x00000001b4e40834 -[NSXPCConnection _sendInvocation:orArguments:count:methodSignature:selector:withProxy:] + 2668 7 Foundation 0x00000001b4e6faa8 -[NSXPCConnection _sendSelector:withProxy:arg1:arg2:arg3:] + 148 8 Foundation 0x00000001b50814a4 _NSXPCDistantObjectSimpleMessageSend3 + 48 9 FileProvider 0x00000001c93b6ba4 -[FPDaemonConnection valuesForAttributes:forItemAtURL:error:] + 428 10 FileProviderOverride 0x000000010e5b9f14 0x10e5b8000 + 7956 11 CoreFoundation 0x00000001b4b7cf14 __invoking___ + 148 12 CoreFoundation 0x00000001b4a46098 -[NSInvocation invoke] + 400 13 CoreFoundation 0x00000001b4a46cc0 -[NSInvocation invokeWithTarget:] + 80 14 FileProvider 0x00000001c9374db8 -[FPFrameworkOverridesIterator callNextOverrides] + 468 15 FileProvider 0x00000001c9374f58 -[FPFrameworkOverridesIterator forwardInvocation:] + 96 16 CoreFoundation 0x00000001b4b7a7d8 ___forwarding___ + 680 17 CoreFoundation 0x00000001b4b7cd60 _CF_forwarding_prep_0 + 96 18 FileProvider 0x00000001c9394cc0 FPCFCopyAttributeValuesForItem + 300 19 CoreServicesInternal 0x00000001b5ebba98 CopyFromFileProvider+ 154264 (__CFURL const*, void const*, void const**, __CFError**) + 88 20 CoreServicesInternal 0x00000001b5ebbe40 ExternalProviderPrepareValues+ 155200 (__CFURL const*, __FileCache*, __CFString const* const*, void const**, long, void const*, __CFError**) + 376 21 CoreServicesInternal 0x00000001b5ea8cc0 prepareValuesForBitmap+ 76992 (__CFURL const*, __FileCache*, _FilePropertyBitmap*, __CFError**) + 376 22 CoreServicesInternal 0x00000001b5ea69d4 _FSURLCopyResourcePropertyForKeyInternal+ 68052 (__CFURL const*, __CFString const*, void*, void*, __CFError**, unsigned char) + 220 23 CoreFoundation 0x00000001b4b40768 CFURLCopyResourcePropertyForKey + 140 24 CoreFoundation 0x00000001b4a4d190 -[NSURL getResourceValue:forKey:error:] + 120 25 Foundation 0x00000001b4ec43a0 +[NSFileVersion unresolvedConflictVersionsOfItemAtURL:] + 124 26 UIKitCore 0x00000001b86fcc90 -[UIDocument _setOpen:] + 144 27 UIKitCore 0x00000001b86fbb8c __40-[UIDocument openWithCompletionHandler:]_block_invoke + 676 28 libdispatch.dylib 0x00000001b4814ec4 _dispatch_call_block_and_release + 32 29 libdispatch.dylib 0x00000001b481633c _dispatch_client_callout + 20 30 libdispatch.dylib 0x00000001b481c85c _dispatch_lane_serial_drain + 568 31 libdispatch.dylib 0x00000001b481d290 _dispatch_lane_invoke + 400 32 libdispatch.dylib 0x00000001b4826928 _dispatch_workloop_worker_thread + 584 33 libsystem_pthread.dylib 0x00000001b487d714 _pthread_wqthread + 276 34 libsystem_pthread.dylib 0x00000001b48839c8 start_wqthread + 8Note the app doesn't use a Document Browser: UISupportsDocumentBrowser = FALSE. LSSupportsOpeningDocumentsInPlace = FALSE Using a single NSUbiquitousContainer with NSUbiquitousContainerIsDocumentScopePublic = FALSE

My app stores data files in a ubiquity container. NSUbiquitousContainerDocumentScopePublic is FALSE. After accessing a file from within the app, it is now showing in the Recent files area of the Files app. I would expect that because the ubiquitous container scope is private this should NOT occur. I'm seeing this for other apps that also would not normally be exposing internal files. Anyone else experiencing this? I have filed feedback with Apple and awaiting response.

I'm developing a autoFill credential provider extension.The extension uses an iCloud file which is sharing data between the main application and the extension. Reusing the code to manage iCloud files, I'm not seeing any notication that iCloud has been disabled (or reenabled) for the main application inside the extension.This issue is made worse by the fact that extensions may be terminated - or not. So whilst an extension continues to run it appears to maintain the same iCloud state from startup. Calls to NSFileManager.defaultManager.ubiquityIdentityToken always return the same value within the extension (and NSUbiquityIdentityDidChangeNotification is never posted). This means after informing the end user that iCloud needs to be enabled, it is unable to detect that it has been enabled, until the extension process is eventually terminated and then restarted.