Post not yet marked as solved
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?
Post not yet marked as solved
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
Post not yet marked as solved
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.
Post not yet marked as solved
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.
michaelr.