Tk Source Code

Can [1bc92655] please be backported to 8.6/9.0? Thanks

I think this is sufficient, so I will close the ticket.

--- macosx/tkMacOSXMenus.c
+++ macosx/tkMacOSXMenus.c
@@ -23,7 +23,12 @@ static void ShowAboutIdleTask(void *clientData) {
     int code = Tcl_EvalEx(interp, "tkAboutDialog", TCL_INDEX_NONE,
 			  TCL_EVAL_GLOBAL);
     if (code != TCL_OK) {
-	Tcl_BackgroundException(interp, code);
+	// Equivalent to how -[TKApplication orderFrontStandardAboutPanel:]
+	// falls back to calling [super orderFrontStandardAboutPanel:NSApp].
+	SEL selector = @selector(orderFrontStandardAboutPanel:);
+	Method method = class_getInstanceMethod([NSApplication class], selector);
+	IMP imp = method_getImplementation(method);
+	((void (*)(id, SEL, id))imp)(NSApp, selector, NSApp);
     }
     Tcl_ResetResult(interp);
     Tcl_Release(interp);

I think even developers could find that error message confusing, whether or not their program uses eval/bgerror/etc. Several Tkinter users had encountered [310c74ec], for example, and it seemed not uncommon for such issues to prompt them to believe (or be told) that their code was responsible for the error, but then not figure out exactly why.

I think I would lean towards emitting a message.

In a real app, it is hard for me to imagine how a user would be in the
situation where an "About" dialog is being requested from a deleted
interpreter.  A user might open the dialog to check the version of
the software or on the first run to find out whatever information
is available.  But that is not likely to involve a deleted interpreter.

So the message would be aimed at developers, and they deserve to
get a message. I don't know what is wrong with "attempt to call eval
in deleted interpreter"

Thank you.  Of course you may.

I did not see any problem when running that script, but I added the
preserve call anyway.  I released _eventInterp in the idle task itself.
I assume that is what you had in mind.

I just pushed that change to the tip of main.

Reopening this if I may. The current fix passes _eventInterp to Tcl_DoWhenIdle() without preserving it, which leaves open the possibility of a use-after-free if _eventInterp is deleted before showAboutIdleTask() is called. The following tclsh script triggers the problem, at least after [8e32cb7e] and [1ab7a5f2] are fixed first:

interp create i
interp eval i package require Tk
interp eval i proc tkAboutDialog x {{puts unimplemented}}
interp eval i ::tk::mac::standardAboutPanel
interp delete i
update idletasks

I have merged bug-33b3af1cea into 9.1, 9.0 and 8.6.  I am closing this
ticket now.

Here is my current best guess.  People claim that the menubar display
has been completely changed in macOS 27 and now uses a private undocumented
framework named MenuBarClientCore.  Evidently that framework changed the
behavior of the runloop which is started when a menu is opened. In macOS 26
a runloop is started in NSEventTrackingRunLoopMode which terminates when
a menuitem is selected.  The action for the menuitem is then called in Tk's
default state, which has a nil runloop mode.

My experiments indicate that in macOS 27 a runloop is first started in
NSDefaultRunLoopMode which does unknown things before starting a runloop
in NSEventTrackingRunLoopMode.  When that runloop ends the action for the
selected item gets run before the parent default runloop stops.  Apparently
the default runloop does not stop until the menuitem action returns.  But
Tk does not attempt to process any events from the AppKit event queue unless
the runloop mode is nil (and possibly it would not be allowed to do that
if it did attempt to).  Therefore, if user input, such as pressing the
OK button in a dialog window, must be processed before the command returns
this means that the command can never return and the default runloop will
never stop and Tk will never be able to process a user event again.  The
idle task workaround allows the menuitem action to return immediately,
which allows the outer default runloop to end and Tk is then able to
return to processing user events.

I can see that when either the NSMenuDidBeginTrackingNotification or the
NSMenuDidEndTrackingNotification is received by Tk the current runloop
mode is NSDefaultRunLoopMode in macOS 27 but is nil in macOS 26.

Also, the Tcl function TclpWaitForEvent, which starts a runloop to process
one event from any event source, tracks the runloop nesting level.  I can
see that in macOS 26 the nesting level never exceeds 2, but in macOS 27
it reaches 3.

This data is at least consistent with my guess of what is happening.

Given all this, I think the idle task workaround is the most reasonable
way to deal with this.  (We are lucky that you noticed that it works!)
This has been implemented in the bug-33b3af1cea branch and it was
verified that it allowed the Python IDLE.app (which launches dialogs
from menu item callbacks) to work again.

My plan is to merge the bugfix branch into 9.0 and 9.1, and perhaps also
into 8.6, although I would prefer that people not use 8.6 on macOS 27
and later.

Yes, I think it is a blocker for 9.0.5.

I have pushed a bugfix branch bug-33b3af1cea which uses the workaround
suggested here.  All menu actions are run as idle tasks instead of being
called directtly.

I am not comfortable with this workaround because I cannot explain why it works.  However, as far as I can tell, it does work.

I suspect the answer to why it works may be buried in the Tcl notifier for
macosx.  If that is correct, changing the Tcl notifier might be a better
fix.

This looks like a blocker for Tk 9.0.5.

+1

Correction!  When I said "thread" with respect to menus and file dialogs I
was not correct.  I should have said "Runloop Mode".  All of the events are
processed by the main thread, but menus and file dialog events are handled
in different runloop modes.  For menus, the runloop mode is called
NSEventTrackingRunLoopMode and for file dialogs it is called NSModalPanelRunLoopMode.

So this is probably caused by an Apple bug which broke the transition from NSEventTrackingRunLoopMode to NSModalPanelRunLoopMode when that transition occurs by calling NSOpenPanel or NSSavePanel from a menu action.

If the bug persists after the OS release Tk can probably work around it
the same way - by calling NSOpenPanel and NSSavePanel from an idle task.

We have to wait and see if they fix it.

I am glad there is a simple workaround, but I would like to know what the
cause of the hang is, and what changed in macOS 27 to cause this.

Some things I know are:

* Opening a menu launches a separate thread which handles *all* mouse and
  key events belonging to the Tk application.  Tk does not receive any of
  these events while a menu is open.

* In order to make Tk timer tasks get processed while a menu is open (for
  example, to keep the pendulum swinging in the pendulum demo while a menu
  is open) Tk launches its own separate thread when a menu is opened.  The
  Tk thread processes Timer tasks only.

* Opening a file dialog also causes Apple to create a separate thread which
  manages all mouse and key events targeting the dialog while hiding all of
  those events from Tk.

One thing to keep in mind is that this may be an Apple bug which may get
fixed before macOS 27 is released.  However, it may also be an intentional
change.  The fact that it can be worked around by just delaying the launch
of the file dialog suggests a race condition has been created which can
somehow prevent Apple from launching the thread to manage the file dialog.
It is hard to imagine that Apple would intentionally create a race condition
like that.  So I am leaning towards the idea that this is an Apple bug.

The race condition theory may be wrong, however. I believe that when a menu
item is selected which runs a Tk command, the Tk command may actually get run in
the thread which controls the menu.  So the issue may be whether a file dialog
thread can be launched by a thread which is not the main thread.  Maybe that
used to be possible but is not any longer, due to some change in macOS 27.
This alternate theory is consistent with this report, because the workaround
changes the menu action from "launch file dialog" to "add command to launch
file dialog to the idle queue".  The idle command would then be run by the
main thread instead of by the menu management thread, so the file dialog thread
would be launched by the main thread with the proposed workaround.