Thanks a lot for the reply! I had a bug I recently introduced in my app where I missed syncing model/UI with a selection change. I was already using the target-action but my app is pretty large and also programmatically changes the selection in many different places. As far as a I know there is no way to pick up all selection changes globally (other than the binding) so I decided to try the binding but that didn't work out as described in the original post. So instead of the binding to resolve I'm now overriding four different set methods (in addition to responding in the target-action). - (void)selectRow:(NSInteger)row inColumn:(NSInteger)column; - (void)selectRowIndexes:(NSIndexSet *)indexes inColumn:(NSInteger)column -(void)setSelectionIndexPath:(NSIndexPath *)selectionIndexPath -(void)setSelectionIndexPaths:(NSArray<NSIndexPath *> *)selectionIndexPaths Maybe overriding only two is required, not sure but if so that is undocumented and subject to change anyway. So a binding or a notification like NSBrowserSelectionDidChangeNotification would be preferred. and FBs from real-world cases like yours raise the priority on those gaps. I've been filing enhancement/bugs on NSBrowser for nearly 10 years. Searching Feedback Assistant I filed something about selection change in 2017: FB5335246 My most recent NSBrowser Feedbacks (though unrelated to this): FB22704799 FB22641162 FB5417493 FB20298148 Old school: FB5447156 -- Unfortunately NSBrowser seems to be frozen in time. I've thought about writing my own several times over the years but I'm always working on other things and I usually find a workaround for the browser (which takes a long time to write and is frustrating) so I haven't been able to motivate myself to write my own completely from scratch. I think column view is like everyone's favorite view type in Finder...so it would be great if this control got some love from Apple!

So I decided to give up on this because I don't think it is currently possible. There is a button on iPadOS "Restore Recently Closed Windows" in the upper left corner that becomes visible when you are in the app switcher... so I guess iPadOS keeps some closed windows in the openSessions set but there appears to be no way to distinguish these windows verses the archived ones in the app switcher. I could be wrong and maybe I missed something, but not worth spending anymore time trying to figure it out.

So I just discovered a related misbehavior for inherited properties. FWIW I'm in ObjC. If your superclass declares a public IBOutlet and then in your xib your subclass connects it, now Interface Builder incorrectly displays a warning triangle saying that your class has no such outlet. Example: @interface MySuperClass : NSObject @property (weak, nonatomic, nullable) IBOutlet NSMenu *menuSampler; @end @interface MySubclass : MySuperClass @end Use MySubclass in xib and connect outlet to menuSampler and I get a warning triangle. Not sure if this is required to reproduce but the superclass is in another framework.

Is it only with objC code or Swift as well ? Xcode 26.5: In new iOS storyboard project I can connect IBOutlets from the Assistant editor in Swift...looks fixed there. Connection bubbles show. But in Objective-C the connection bubbles are completely gone from source files so in ObjC the problem is not fixed, actually worse. You can connect from the Connections Inspector though, but Xcode won't display "connection" status in ObjC source. So for me, because I still use ObjC the problem is worse. Hope that's not intentional. That would be very very negative evolution. You mean typing xibs by hand doesn't make you more productive!? 😂

No problem. I also just noticed if you do the selection quite rapidly the selection box can also get stuck (no right click required). Seems to happen when collection view is grouped though I'm not sure exactly if that has anything to do with it (so in Finder "Use Groups" with section headers). Also if you mouse drag while you are doing the selection box outside the collection view (to the point where your cursor extends into the sidebar in Finder) things sometimes stop working. What things stop working? Mouse clicks. The collection view temporarily stops responding to mouse clicks. Using the arrow keys to move the selection 'fixes it' then mouse clicks start working again. My app uses an NSSplitView and has sidebar and a collection view so my app is impacted the same way. My hope is because Finder is impacted they may fix. Fingers crossed. In my app when this mouse clicking problem happens I am getting -mouseDown: in my NSCollectionView subclass (and calling super) but the collection view just doesn't modify the selection when you click on items nor does it deselect when you click on the background.

I filed FB22716998

This seems to avoid the issue: -(void)rightMouseDown:(NSEvent*)theEvent { if ((NSEvent.pressedMouseButtons & (1 << 0)) != 0) { // Not at the same time, dog. return; } [super rightMouseDown:theEvent]; }

IFIRC I’ve had success working around this kind of issue by getting the transitionCoordinator and adding an empty animation alongside it and then presenting the view controller in the completion handler. Fallback and just present it if transition coordinator is nil. https://developer.apple.com/documentation/uikit/uiviewcontroller/transitioncoordinator?language=objc I don‘t SwiftUI though so Albert‘s answer might be the better one for your project

You should be able to do this. Try using: + (void)restoreWindowWithIdentifier:(NSUserInterfaceItemIdentifier)identifier state:(NSCoder *)state completionHandler:(void (^)(NSWindow * _Nullable, NSError * _Nullable))completionHandler NS_SWIFT_UI_ACTOR API_AVAILABLE(macos(10.7)); https://developer.apple.com/documentation/appkit/nswindowrestoration/restorewindow(withidentifier:state:completionhandler:)?language=objc Appkit restores window frames automatic but if something funky is going on and that is being done too late you can ensure the window size is restored early by setting it yourself in +restoreWindowWithIdentifier:state:completionHandler: before you call the completionHandler.

I experience this issue every day, across many different apps, all the time on my iPhone SE 3rd gen. I've just been ignoring because I've been kind of busy with macOS. But really an annoying bug. Happens in Safari all the time. Usually after playing a video on YouTube. But it happens other times too. Seeing this thread was posted way back in September is kind of demoralizing I think.

Err so 304 is the design time height of the first row I have in Interface Builder. And for some reason NSTableView tries to force that as the line scroll from within -tile. All my other rows are not that big. I guess I can reorder the rows in the xib, or just keep calling super with my own value. Edit: Also changing "Row sizing style" from "Match Canvas" to "Custom" allows me to change the row height to whatever I want. NSTableView apparently forces the value of row height as the scrollView's lineScroll. Does it need to be reset in every -tile call? I'm not sure. But I'm implementing heightOfRowByItem: so just setting the row height in the xib is the way to set line scroll without actually changing the height of the rows (which are not all the same)

I was able to cook something up with constraints and computing the styles for the date formatter with an offscreen label, then taking the best fitting style and using it on the onscreen label. BUT I'm still a teeny bit nervous about all this because: Changing the date format style causes.. the stringValue of the NSTextField to change which can cause.. The text field to invalidate its intrinsic content size (sometimes I guess). I don't really know my bounding width until I'm in layout. It's easy to avoid infinite loops in my code but autolayout with its strict exceptions and rules, implicit layout invalidation etc., it is not so easy to guard against rules that are not well documented. B/C autolayout claims it is not legal to change layout in the middle of layout how can I change the date format safely during layout? I'm not hitting the exception anymore which is good but as an extra precaution I have my NSTextFIeld subclass override -invalidateIntrinsicContentSize and do nothing..because I don't want setStringValue: to invalidate the layout, I want to adjust the .stringValue to live within the layout I already have. I hope that makes sense. Please don't be so strict throwing exceptions in Autolayout! Layout bugs, overlapping views, etc are typically not fatal errors IMO. Sincerely, Macho

I'm working on rewriting a little piece of code in my app. I have a label that displays a date and adjusts the date format (growing and shrinking based on available width). I take measurements using -sizeToFit and also make sure I don't end up in an infinite loop. But I get: **The window has been marked as needing another Update Constraints in Window pass, but it has already had more Update Constraints in Window passes than there are views in the window. ** On this particular label I'm not using constraints because in this case that would seem to add a lot more complexity and I turn off translatesAutoresizingMaskIntoConstraints. At least in UIKit, I don't recall ever having issues calling -sizeToFit in -layoutSubviews or -viewDidLayoutSubviews. I guess I'm going to have to modify my approach and take my measurements offscreen. Autolayout is cool but I think it is sometimes too strict.

Well when I first wrote this code (probably ~8 years ago or so), using the atomic flag with RTFD file wrapper would overwrite an existing file. Without the atomic flag, the operation would fail if the file exists but the existing file would remain (which is my desired behavior). At some point this changed and now not specifying the atomic flag, does not overwrite an existing file as I already mentioned but for some reason fails while also discarding the existing file. I cannot think of a situation where that behavior makes any sense or is useful other than to make it easy to write code that causes accidental data loss. If overwriting is always desired (atomic or not) then an existing file shouldn't ever be an error reason I don't think. I guess I'm grumpy about the behavior changing unannounced in a way that impacts the behavior of apps. If the plan is to keep it this way going forward I think a big bold note should be added to the documentation "if you try to save to a URL that already exists, the operation will fail and the file will disappear"). In any case I've modified my code to write to a temp file first, and then try to move it afterwards. I guess you could argue that this is a better design and I'd agree. Perhaps I should have always done it this but the way I had it wasn't "wrong" until the rug got pulled.

So it sounds like a long shot I guess but I filed FB22492490 anyway because I don't really understand the point of failing with NSFileWriteFileExistsError if the existing file isn't going to be protected. Also suggest in the FB that documentation should be added.