IDLE on macOS 27 hangs when a menu command opens a dialog

[Universe-Of-The-Creator]

Bug report

Bug description:

IDLE on macOS 27 hangs (beach ball, Force Quit) when a menu command opens a dialog or waits on the shell socket. The process is not idle-locked by user code. The main thread is stuck inside the macOS menu-bar callback.

What happens

macOS 27.0 (build 26A428) delivers menu clicks through MenuBarClientCore 1.0 while Tk is already inside its event loop. Tk runs the menu command on that stack. If the command opens a modal dialog, or enters another Tk event loop that blocks in select (IDLE waiting on the Run/Shell subprocess), the menu-bar call never returns. The window stops redrawing. Activity Monitor shows the process as not responding. Force Quit is the only way out. Unsaved editor text is lost.

This did not happen on macOS Tahoe 26.6.2. It started after the update to macOS 27 (this machine: 2026-09-10). The Python.org installers were not changed at that time.

Reproduced with

Official python.org IDLE.app, native arm64, Rosetta not involved.

• Python 3.14.7, Tk 9.0.4. Hang sample: main thread in MenuBarClientCore â�� Tk â�� nested event loop â�� select / sock_accept.
• Python 3.13.14, Tk 8.6.18. Same stack from IDLE > Settings (::tk::mac::ShowPreferences). Settings is enough. No user script required.

Reliable steps:

1. Install the python.org macOS package for 3.13 or 3.14.
2. Launch IDLE.app.
3. Click IDLE > Settings in the menu bar.
4. Beach ball. The Settings window does not finish opening. Force Quit.

Save As and Run Module can take the same path, because they open a dialog or wait on the shell socket before the menu callback returns.

Expected

The menu action returns, then IDLE opens Settings (or the save dialog, or runs the module). The window stays responsive.

Cause

The hang is the nested event loop inside the menu-bar callback, not IDLE's editor code and not the user's program. A menu command that returns immediately, then does the real work on the next Tk turn, does not hang. Verified on both 3.13.14 and 3.14.7: after that deferral, IDLE > Settings opens and the process stays in Tk_mainloop.

Suggested fix

On macOS, IDLE should not run dialog or shell work inside the menu-bar callback. Schedule those commands with after idle (and the same for ::tk::mac::ShowPreferences, ShowHelp, Quit, and the standard About panel) so MenuBarClientCore's call returns before Tk nests another loop.

This should live in idlelib (macosx.py or the menu setup), not as a per-user extension. Other Tk apps on macOS 27 have the same OS interaction; Apple is being asked, separately, to make the menu bar tolerate a nested run loop. IDLE still needs the deferral so current macOS 27 users are not stuck.

Environment

• macOS 27.0 (26A428), MenuBarClientCore 1.0 (97.0.9.402)
• Previous OS, where this did not happen: macOS Tahoe 26.6.2
• CPython 3.13.14 (Tk 8.6) and 3.14.7 (Tk 9.0), both from python.org macOS installers
• Native arm64

CPython versions tested on:

3.14, 3.13

Operating systems tested on:

macOS

[terryjreedy]

@Universe-Of-The-Creator Thank you for the report. Can you test your proposed fix on one dialog that fail, such as About? Can you apply PRs to test?
@ronaldoussoren @ned-deily Do either of you know anything about this nasty macOS 27.0 regression? Which of you upgraded so you can test proposed patches?
@serhiy-storchaka This is not my personal priority, but seems nasty for mac users who install 27.0+. Have any suggestion?

[ned-deily]

Thanks, @Universe-Of-The-Creator, for the report and the detailed description and analysis. The hanging behavior is indeed easily reproducible on macOS 27.0. And, just to be clear, it is not limited to python.org macOS builds running on 27.0.

@culler, @serhiy-storchaka, any thoughts for a workaround?
@Universe-Of-The-Creator, confirming that you have opened an issue with Apple?

[Universe-Of-The-Creator]

Tested the workaround on About, with the local wrapper removed first.

Without the wrapper, IDLE > About IDLE does not open. The process stays inside the menu-bar callback, enters a nested Tk event loop, and blocks in select. Accessibility cannot read the window list. Reproduced on the official python.org IDLE.app, native arm64, macOS 27.0 (26A428):

• Python 3.13.14 / Tk 8.6.18
• Python 3.14.7 / Tk 9.0.4

With the wrapper restored, About opens on both versions. The process stays in the normal Tk main loop. No hang.

The workaround is still a user extension, not an idlelib patch. The menu command returns immediately, then the real work runs on the next Tk turn (after idle). About, Settings, Help, and Quit are deferred that way.

Yes. This Mac can test a PR or a small idlelib patch. The local wrapper has to be turned off first, or it will mask the result.

Apple Feedback Assistant report: FB24915676 (Menu Bar, application unresponsive, sysdiagnose attached). That is the external path into Radar.

[serhiy-storchaka]

This is Tk ticket 33b3af1cea, reported for the macOS 27 beta: a modal dialog opened directly from a menu command hangs, while the same dialog deferred with after idle works. So yes, deferring is the right workaround. The proper fix belongs in Tk (cc @culler), so that it works for all Tk applications, but until then IDLE can defer its menu commands and the ::tk::mac::* handlers (ShowPreferences, ShowHelp, Quit, About) with after_idle() on macOS.