NSInternalInconsistencyException assertion from [NSRemoteView containingWindowWillOrderOnScreen:] on macOS 27 (26A5378j)

Question

Created 1w

Replies 1

Boosts 2

Participants 2

Is anyone else getting these assertion crashes on developer beta 3 of Golden Gate? I've gotten more than a dozen crash logs from users running macOS 27 (26A5378j) that all look like this:

assertion failed: '<NSRemoteView: 0x79cb366700 com.apple.SafariPlatformSupport.Helper SPCompletionListServiceViewController> notified of <NSStatusBarWindow: 0x79cbef7480> but expected (null)' in -[NSRemoteView containingWindowWillOrderOnScreen:] on line 4221 of file /AppleInternal/Library/BuildRoots/4~CSuOugB1YCxzYMPRWEumvvfCTNtf98eItTmsbJU/Library/Caches/com.apple.xbs/TemporaryDirectory.N8fh9t/Sources/ViewBridge/NSRemoteView.m

but with various windows from my app after "notified of".

They're getting thrown when one of my windows is made frontmost, either using NSWindow.orderFrontRegardless or NSWindow.makeKeyAndOrderFront, or (in the case above) when my status item is shown. It's intermittent - I've been unable to reproduce it so far - but definitely happening repeatedly based on my Sentry crash logging.

Is this a bug in Golden Gate b3, or am I doing something to provoke this? I've submitted it via Feedback Assistant (FB23642313).

Thanks

Jon

P.S. Full stack trace attached for the exception thrown when the assertion fails for NSStatusBarWindow

NSInternalInconsistencyException stack trace.txt

Answer 1

pawelmtw OP

6d

We're seeing this error as well. In our case, it occurs when a child NSWindow contains an editable text field: closing that window and opening a new one triggers the crash. We've found that removing the editable text field prevents the crash, but this is clearly a bug in Golden Gate Beta 3...