closing the trade dialog deadlocks Textual's screen teardown — App.pop_screen's do_pop waits forever on the dialog's child widgets to shut down, the event loop goes idle and stops reading input, and Ctrl‑C is dead

[MatthewCarven]

The short version of the bug: closing the trade dialog deadlocks Textual's screen teardown — App.pop_screen's do_pop waits forever on the dialog's child widgets to shut down, the event loop goes idle and stops reading input, and Ctrl‑C is dead because raw mode turns it into an unread keystroke rather than a kill signal. Reproduces on two Textual versions, on cancel as well as buy. The four buttons in the dialog are a strong contributor.

Trader Pro.zip

docs/freeze-bug/README.md — the full write‑up: symptom, root cause, what we ruled out, how to reproduce, and two fix directions for later.
tests/test_tui_trade_dialog_freeze.py — a cross‑platform regression test (subprocess + wall‑clock timeout, so it runs on Windows — no pexpect needed). It's marked xfail today; once the dialog is fixed it'll XPASS, which is your signal to drop the marker. Verified it currently detects the freeze.
scripts/repro_trade_dialog_freeze.py — minimal repro: headless by default (Windows‑safe), or --pty to drive the real terminal app on Unix/WSL.
docs/freeze-bug/asyncio-task-dump.txt and thread-stacks.txt — the actual diagnostic captures (the stuck do_pop with every dialog widget still alive; the idle loop + live input thread).
A worklog entry summarising it, and a note that the earlier "should no longer freeze" line was wrong.

(THANKS Claude totally phoned this one in guys)

[github-actions]

We found the following entries in the FAQ which you may find helpful:

• How do I center a widget in a screen?
• Does Textual support images?
• Why doesn't Textual look good on macOS?

Feel free to close this issue if you found an answer in the FAQ. Otherwise, please give us a little time to review.

This project is developed and maintained by Will McGugan. Consider sponsoring Will's work on this project (and others).

This is an automated reply, generated by FAQtory

[MatthewCarven]

screen.remove() waits for the dismissed dialog's child widgets to shut down (each widget has
its own message-pump task). In this app that wait never completes — do_pop is stuck
forever and every dialog widget is still alive. With the App's message loop parked inside that
never-finishing do_pop, the event loop goes idle and stops dispatching input.

Ctrl-C does nothing because Textual puts the terminal in raw mode: Ctrl-C arrives as an
ordinary keystroke (byte 0x03) for the app to handle, not as a SIGINT the OS can use to kill
the process. Since input is no longer dispatched, that keystroke is simply never read.

The smoking gun is the live asyncio task dump taken at the moment of the freeze
(asyncio-task-dump.txt):

test_tui_dialog_button_count.py

**

Here's the verdict from the button experiment — and it's a plot twist:

Buttons | Dismiss (Esc) | Dismiss (Buy) -- | -- | -- 0 | FROZEN | FROZEN 1 | FROZEN | FROZEN 2 | FROZEN | FROZEN 3 | FROZEN | FROZEN 4 | FROZEN | FROZEN

The buttons aren't the culprit. Even with zero buttons — a plain info line + input box — the dialog still freezes on dismiss. So my earlier "the four buttons are a strong contributor" note was wrong, and I've corrected the bug report.

I kept pulling threads to be sure, and ruled out (one factor at a time, all in the real app):

• dismiss style — call_later vs direct dismiss(): both freeze
• where the info text is built — in compose vs an on_mount .update(): both freeze
• the action handlers (on_input_submitted / _act): deleting them doesn't help

Yet a separate, near‑identical minimal modal class stays perfectly responsive. So this isn't any single ingredient — it's a fragile race in Textual's teardown of this particular screen. That's exactly why poking at the structure has been whack‑a‑mole, and it confirms the dependable fix is to rebuild the dialog fresh or drop the modal, not tweak it.

What I added to your repo:

• tests/test_tui_dialog_button_count.py — parametrized over 0–4 buttons, verified it reproduces (collects as 5 cases, reports xfailed).
• Switched both freeze tests to an xfail(strict=False) decorator, so they actually run and will XPASS (flagging themselves) the moment the dialog works again.
• Updated docs/freeze-bug/README.md and the worklog with the button‑count finding.

Methodology note so you can trust the numbers: I cross‑checked the headless run_test detector against the real terminal (PTY) on a known‑good case — they agree — so the FROZEN/ALIVE results above are faithful, not test‑harness artifacts.

**

[MatthewCarven]

0.50.0 stays alive! The bug was introduced after the repo's declared floor (textual>=0.50). Your installed version is much newer, which is why it freezes. Let me bisect to find exactly where it broke — testing the midpoint, 0.68.0.Ran a commandRan a command0.68.0 alive too — narrowing. Break is between 0.68 and 0.86; testing 0.77.0.Ran a commandRan a commandBetween 0.68 (alive) and 0.77 (frozen). Testing 0.73.0.Ran a commandRan a commandBetween 0.68 (alive) and 0.73 (frozen). Testing 0.71.0.Ran a commandRan a commandDown to one version between them — testing 0.72.0 (and confirming the boundary).

[MatthewCarven]