Tkinter "wait_window()" will hang and not spawn window from root with "after_idle()" on MacOS

[nalvarez508]

Bug report

Using Toplevel wait_window() from Tkinter on MacOS via after_idle() before any root windows will cause the process to hang and the windows are never spawned.

Expected behavior

The waited for window (Toplevel) will display before the main window (Root). Once some action is taken on the waited for window, in this case "Press me" button, the root window will be displayed. The user cannot access or see the root window until the "Press me" button is pressed.

Actual behavior

• Using after_idle() - neither window spawns, application hangs
• Using a button to call the waited-for-window from root, the waited-for-window spawns and will return a value to root
• Using after() and withdraw/deiconify - expected behavior via workaround

MREs follows:

This will not work due to the waited window being called before the root window is displayed using after_idle.

import tkinter as tk

class MainWindow(tk.Tk):
  def __init__(self):
    super().__init__()
    self.title("Hello")
    tk.Label(self, text='Hi there').pack()

    self.after_idle(self.waitforit)
    self.mainloop()
  
  def waitforit(self):
    x = WaitedForWindow(self).show()
    print(x)

class WaitedForWindow(tk.Toplevel):
  def __init__(self, parent: tk.Tk):
    tk.Toplevel.__init__(self, parent)

    tk.Button(self, text='Press me', command=self.destroy).pack()

  def show(self):
    self.deiconify()
    self.wait_window()
    return True

if __name__ == "__main__":
  MainWindow()

Spawning a window (without calling the .show() above) will work fine, but a value cannot be returned of course, and both windows will spawn. Running the same MRE in 3.9.0 works fine.

However, if the main window's class is changed to spawn the waited window via button-press, everything works fine, but the behavior is not what we want:

# self.after_idle(self.waitforit)
tk.Button(self, text="Wait for window", command=self.waitforit).pack()

or by using after() [current workaround] we get the correct behavior via some extra steps.

class MainWindow(tk.Tk):
  def __init__(self):
    super().__init__()
    self.title("Hello")
    tk.Label(self, text='Hi there').pack()

    self.after(0, self.waitforit)
    self.after(0, self.withdraw)
    self.mainloop()
  
  def waitforit(self):
    x = WaitedForWindow(self).show()
    print(x)
    self.deiconify()

Your environment

• CPython versions tested on (using MRE 1):
  • 3.9.0 (working) [^+]
  • 3.10.9 (non-functional) [^]
  • 3.11.1 (non-functional) [^+]
  • 3.12.0a3 (non-functional) [^]
  • ... all 64-bit
• Operating system and architecture: MacOS Mojave 10.14.6 x64 (^), MacOS Monterey 12.6.2 (+)
• Tkinter version: 8.6.12 [^+]
• 3.9.0, 3.11.1 tested in and out of bare virtualenv [^+]
• additional tests from colleagues:
  • W11, 3.10.5 (working)

Linked PRs

• gh-100617: Add a timeout parameter to tkinter wait_window() #152620

[nalvarez508]

Tested on Windows 11 with 3.10.5 and it is working there

[nalvarez508]

Additional tests performed on MacOS Monterey with the same results, see OP updates.

[nalvarez508]

A workaround has been discovered and tested on MacOS Monterey 12.6.2 using Python 3.11.1. See the final code snippet using after().

[chrstphrchvz]

I can reproduce the hang even with Tk Aqua 8.6.13.

Due to limitations in the current Tk Aqua implementation on when it can run any low-level widget drawing code, it relies on an additional idle event handling loop not present in Tk on other platforms. This idle event loop is only meant for running widget drawing code, and can lead to issues if it tries to handle other already-queued idle events.

A spindump of the process shows that the self.waitforit() call scheduled with after_idle() is being handled during this Tk Aqua idle event loop, and wait_window() never returns.

I do not know if the current Tk Aqua implementation can avoid this issue (especially without introducing other issues). A revised Tk Aqua implementation (discussed at https://core.tcl-lang.org/tk/tktview/3e9e82bcfe) would not have the problematic idle event loop, but it is still a work in progress.

[serhiy-storchaka]

This is an Aqua-specific interaction (an after_idle() callback scheduled before any window is shown), so it can't be fixed at the Python level.

PR #152620 adds an optional keyword-only timeout to wait_window() so the call can return False instead of hanging indefinitely. It bounds the hang rather than fixing the underlying macOS behaviour.