FB12007249

I filed FB12007198

Okay so I have two window scenes open (windows) and the auto selecting was happening in one window and not the other. I figured out how to trigger it: UITableView just starts doing this after I move the selection with the arrow keys shortly before doing a swipe delete. The focus system just acts bizarre. I really didn't need to run into another one of these UITableView bugs... errr.. I'll see if I can come up with something to prevent it tomorrow. Anyone else got anything on this?

Ended up making a AppKit project that uses WKWebView, and duplicated the code I need to test in the AppKit project. Using the -_setDeveloperExtrasEnabled: method works when building under AppKit.

Searched developer.apple.com trying to find info about this. I cannot find anything. If there is a way to do this it doesn't appear to be documented. I filed FB12004725

Just to add, I make the call to -loadHTMLString:baseURL: in -viewWIllAppear:. I use a BOOL to make sure I only call -loadHTMLString:baseURL: once since viewWillAppear: can be called multiple times. This is how my code has always been. What's weird is if I move the -loadHTMLString:baseURL: call to -viewDidAppear: loading appears to be a bit faster (not as fast as it should be though, but better) even though -viewDidAppear is called after viewWillAppear. Is it just in my head or is WKWebView trying to optimize and it's actually throttling/delaying the page load? If so it seems to be trying too hard to optimize the window is visible and active and I see my spinner for way too long. Is it waiting for some window state to finish "loading' and draw on screen?

I was able to figure this out. I had thought the directory share would auto mount on the guest but you have to mount it from Terminal on Linux.

targetScene is nil on Mac. For my app I'll just create a new window (new window scene). On iPad I assume it just picks the most active scene but I'll have to test it.

So it doesn't appear to be possible to determine when a UISplitViewController is in a column resizing event. Would be great to be able to determine this to be able to optimize the number of layout passes until after the column resize event finishes... FB11775512

Ya I'd just keep using the cell based API and suppress the deprecated warning then...and just file a bug (or wait if you already filed it). Good news is if they never acknowledge your bug they probably aren't paying too much attention to this anyway....the deprecated API seems very unlikely to break anytime soon.

Take out your PathControlItem subclass. Add a property on PathControl that maps the the path control item titles to your custom data (assuming each path control item has a unique title). Just change the code from my previous response to use the title as the dictionary key instead of NSURL if you aren't setting a URL. //Add this to PathControl. @interface PathControl : NSPathControl //Set this. @property NSDictionary<NSString*,Whatever*>*representedObjectsForPathItemTitles; -(Whatever*)representedObjectForPathControlItem:(NSPathControlItem*)item; @end @implementation PathControl -(Whatever*)representedObjectForPathControlItem:(NSPathControlItem*)item { return [self.representedObjectsForPathItemTitles objectForKey:item.title]; } Unless your titles aren't unique, in which case you'd have to figure out another way to do this.

That's the incredible thing: sender.pathItems.firstIndex(of: sender.clickedPathItem!) always returns nil, even if the clicked path item has the same address as the corresponding item in the path items array. Even sender.pathItems.firstIndex(where: { $0.description == sender.clickedPathItem!.description }) returns nil. And when executing that print statement more than once one after the other, each item always has a different address. Not sure. I don't have time to test this thoroughly but try overriding the pathControlItems setter to see if you or the system are resetting the array unexpectedly. How are you creating each NSPathControlItem? In any case as long as each NSPathControlItem URL is unique you can just hold whatever data you want to associate with each path item like so: @property NSDictionary<NSURL*,Whatever*>*representedObjectsForPathURLs; Then add a method on your path control subclass: -(Whatever*)representedObjectForPathControlItem:(NSPathControlItem*)item { return [self.representedObjectsForPathURLs objectForKey:item.URL]; } This assumes NSPathControlItem doesn't mangle your url strings after they are set.

it doesn't seem possible to get the index of the clicked path item, nor does it seem possible to associate any kind of data with each path item, What happens when you try this: -(void)pathControlAction:(NSPathControl*)pathControl {     NSPathControlItem *clickedPathItem = pathControl.clickedPathItem;     if (clickedPathItem == nil) { NSLog(@"whoops!"); return; }     NSUInteger index = [pathControl.pathItems indexOfObject:clickedPathItem];     if (index == NSNotFound) { NSLog(@"whoops!"); return;  }     //do whatever. } They deprecated the cell based NSPathControl API without introducing proper replacements as you discovered. It's been so many years I get the feeling that they are never going to improve this so it's probably pretty safe to use the cell based stuff even though it's deprecated. But if you don't want to do that your probably can associate data with path control items by subclassing and setting the path control items with some custom objects at the same time. @interface MyPathControl : NSPathControl //Each array must contain the same number of objects. -(void)setPathControlItems:(NSArray<NSPathControlItem*>*)itemsArray withRepresentedObjects:(NSArray<WhateverObject*>*)representedObjectsForEachItem; -(void)setPathControlItems:(NSArray<NSPathControlItem*>*)itemsArray NS_UNAVAILABLE; @end Or something like that. Not great but that's all I can think of.

I had an issue with UITableView starting on iOS 16.2 which seems similar to your issue, but may in fact not be. Are you able to get the NSException reason, name, info, etc.? https://developer.apple.com/documentation/foundation/nsexception?language=objc

Workaround is to do this in all the view controllers automatically being wrapped in the more navigation controller: -(void)willMoveToParentViewController:(UIViewController*)parent {   [super willMoveToParentViewController:parent]; #if TARGET_OS_MACCATALYST   if ([parent isKindOfClass:[UINavigationController class]])     { UINavigationController *navigationController = (UINavigationController*)parent;         [navigationController setNavigationBarHidden:YES]; } #endif }