Active Tcl/Tk 8.6b5 hangs for simple example

The change in versions indicates that this is likely a Carbon to Cocoa transition issue.

The trimmed down report shows more clearly that this is caused by an error occurring in the menu callback. Perhaps tkerror isn't set up correctly, a tkwait is made that shouldn't be, or some interaction between trying to exit the OS X menu loop and get into Tk.

The source of the problem is the vwait in $tk_library/bgerror.tcl. Calling this while we are still entwined with the OS X menu handling event loop gets you stuck. If you do an 'update idle' just before it and disable the "PlaceWindow" call (which has its own update call), you see the window better. Basically though any update here is also bad for similar reasons. Error handling in menus seems problematic.

One workaround for this issue is to define an alternate bgerror proc, cf:

proc bgerror {args} {
puts $args
}

That removes the popup dialog altogether for unhandled errors in Tk-Cocoa.

It's so trivial to rewrite the bgerror command that I wonder if it might make sense simply to define an alternate proc for Tk-Cocoa, something like:

proc bgerror {msg} {
tk_messageBox -icon info -message $msg

}

I've taken a look at the code in tkMacOSXMenu.c and some of the stack traces, and this seems like a very deep, hard-to-find bug. This alternative approach would be much simpler to implement and would solve the issue of the application freezing. Thoughts?

Related bug 3348994 indicates that this is actually a larger issue, and the bgerror trick doesn't solve it. You can use 'after 100' or something (after idle wasn't enough), but it would seem that somehow deferring it properly at the C level seems necessary.

Looks like this bug is a manifestation of issues raised with the Tcl notifier in bug 3028676. I'm going to focus on fixing that bug, as it should resolve this one and others like it.

#3028676, which seems to be driving this issue, is exceptionally complex and beyond my skills to address at this time. I still maintain that the specific issue with bgerror is so easily fixed (by rewriting the procedure, as I do in my Tk-Cocoa apps) that the underlying bug, while serious, is not a showstopper.

Indeed, the rewriting of bgerror solves this issue. Thanks a lot.
Unfortunately, it does not solve the other issue #3348994 (with same freezing outcome) when a dialog box is opened in response to a menu shortcut. (This is still critical for us; currently the only solution would be to disable menu command-key shortcuts on the Mac version).

Actually the menu shortcut work-around is to defer the command with an 'after 100' (or 150 to be safe on slower machines). It won't be noticeable delay to users, and gets around the issue apparently. However, I feel this is an even worse work-around as it forces many changes in the code (at each command invocation). You could generalize it to a menuLaunchCmd proc.

Thanks a lot for the tip.
It works and seems to have solved all remaining issues in ProB on Mac and Tcl/Tk 8.5/8.6) !

Fixed in fossil trunk and Tk-8.5 Cocoa backport:

http://core.tcl.tk/tk/info/72658182ac