launching a modal dialog in windowDidBecomeMain crashing in macOS 10.13

I don't know enough of the inner workings of NSWindow to have an explanation (some experts here certainly have).

But the message you got in 10.12 seems pretty clear. There's a conflcit with what windowDidBecomeMain is doing and setting an NSAlert that makes the window looses its main status.

I thought you could try to put the alert in windowDidBecomeKey, but the same problem should logically occur (could be worth a try).

So question: do you absolutely need to have this alert called from WindowDidBecomeMain ?

From a user point of view, getting an alert each time the window becomes main would probablybe annoying (so I assume you call this alert on some conditions only).

I have a suggestion:

- post a notification from withing windowDidBecomeMain

- handle the alert in the answer to notification.

Hope that works, I've not tested.

Strange I'm getting a very similar error as well here is the block of code I've narrowed it down to:

- (void)windowDidBecomeKey:(NSNotification *)notification {

if (notification.object == self.window) {

if (!self.window.isModalPanel) {

modelSession = [NSApp beginModalSessionForWindow:self.window];

[NSApp runModalSession:modelSession];

}

}

}

With the same error message:

[General] -[NSApplication runModalSession:] may not be invoked inside of transaction begin/commit pair, or inside of transaction commit (usually this means it was invoked inside of a view's -drawRect: method.)

The exception is thrown as soon as I step through runModalSession

I'm more of an iOS guy so thie legacy macOS is tough to understand. Are you suggesting I should post a notification within windowDidBecomeKey? It seems weird that windowDidBecomeKey is already responding to a notification and I am in turn posting another.

Posting a notification won't help. Notification observers are called synchronously before the post operation returns, so the problematic context (from AppKit's point of view) would be just the same. That is, it would still be inside of a transaction begin/commit pair.

File a bug with Apple. It may really be a bug on their part or maybe they'll tell you you've never been allowed to do what you're doing and it's just being enforced more reliably now.

If you need to work around it in the meantime, deferring the operation as previously suggested is probably your only course.

OK, that doesn't work, Ken had the explanation why.

What I do usually, is call the alert in a queue (to avoid the message you had):

                        DispatchQueue.main.async { // Needed to avoid execution warning OSX 10.12 : [NSAlert runModal] may not be invoked inside of transaction commit (usually this means it was invoked inside of a view's -drawRect: method.) The modal dialog has been suppressed to avoid deadlock.
                            let alert = NSAlert()

                           // build the alert
                            let modalResponse = alert.runModal()
                            if (modalResponse == .alertSecondButtonReturn) {
                                // handle appropriately
                            }
                        }

<<so I assume you call this alert on some conditions only>>

That is correct. It only happens one time and only in a specific set of conditions.

Sorry, forgot to mention that I had filed a bug with Apple on this particular issue before posting here. Sometimes filing a bug with Apple feels like throwing it into an abyss, so wanted to get some discussion going here as well 🙂

This was our backup plan from the start as I mentioned in the original post. I hesitate to mark any of this "correct answer" as this is basically a work around for an issue that doesn't seem to be well documented and could be a bug on Apple's part. I'll post back here if I hear anything from Apple on the bug we filed.

I don't see it as a bug. Apple warned developer in 10.12 that this was a problem.

[General] -[NSApplication runModalSession:] may not be invoked inside of transaction begin/commit pair, or inside of transaction commit (usually this means it was invoked inside of a view's -drawRect: method.)

So it may not desired, but it is an intented (insufficiently documented maybe ?) behavior.

Hi ccianflone,

Thank you for filing a Radar, and for providing a good repro case. I'll make sure it's looked at by the correct engineers.

In the meantime, if it's appropriate for your app's logic, you can likely work around this error by running the modal dialog on a subsequent pass of the main runloop, using e.g.

-[NSRunLoop performBlock:]

The same issue occurs in MacOS 12.1 for my app (written in Swift using Xcode 13.3) during the NSTextView's delegate method:

func control(_ control: NSControl, textShouldEndEditing fieldEditor: NSText) -> Bool
{
    return askUserIfOkayToEndTextEditing()          // Causes a crash the moment the NSAlert is run modally
}

The crash reports on the terminal:

2024-01-03 09:42:35.394910-0700 MyApp[23691:765726] [General] An uncaught exception was raised
2024-01-03 09:42:35.394941-0700 MyApp[23691:765726] [General] -[NSApplication runModalForWindow:] may not be 
invoked inside of transaction begin/commit pair, or inside of transaction commit (usually this means it was
invoked inside of a view's -drawRect: method.)

I've not tested this on later systems. What's weird is that putting up the alert used to work and now doesn't, even though I've not updated my MacOS system recently. So it seems some other condition is triggering the crash. Currently a mystery, but it would be nice to know from Apple what the best practice is for putting up an alert such as this as soon as possible to know how to proceed. The problem is that the delegate method seems completely like the right place to put up such an alert. Alas, not.