Problem statement:
In Create and Update modal dialogs the 'x' keypress (and potentially other keys) is being handled by the application-level keybindings and closes the dialog instead of being inserted into multi-line textarea widgets, preventing users from typing these characters.
Users:
- Interactive TUI users creating or updating work items.
- Support engineers reproducing dialog input bugs.
Example user stories:
- As a user, I want to type the letter 'x' into the Create dialog description textarea without the dialog closing, so I can save my content.
- As a keyboard-focused user, I want all keystrokes in focused dialog textareas to be captured by the input widget and not forwarded to global shortcuts.
Success criteria:
- Repro steps: When focused in the Create or Update multi-line textarea, typing the letter 'x' (and other normal printable characters) inserts the character into the textarea and does not close the dialog. (Measurable: reproduce steps should fail prior to fix and pass after fix.)
- No regression: All existing dialog keyboard navigation and shortcut behaviors (Tab, Shift-Tab, Enter, Escape) continue to work as documented in src/tui/components/update-dialog-README.md. (Measurable: existing dialog tests pass.)
- Tests: Add automated unit/integration tests that cover: (a) typing printable characters in multi-line textareas is captured and not forwarded to app-level key handlers; (b) Escape/Enter behavior remains correct. (Measurable: new tests pass in CI)
- Documentation: Update dialog-related docs (README, code comments) to record the change. (Measurable: docs updated in the same PR)
- Full project test suite must pass with the new changes.
- All related documentation is updated to reflect the changes, including code comments, README, and any relevant wiki or docs site entries.
Constraints:
- Avoid large refactors; prefer targeted fix in focus/key handling so this can be landed quickly.
- Maintain behavior parity for other dialogs that rely on the same focus/key handling.
- Tests should run reliably in headless environments used by CI (avoid flakey timing-based tests).
Existing state:
- Work item WL-0MO6ZDLJ5001JUQN created and marked in-progress (title: "Create/Update dialog: keystroke 'x' passes through and closes dialog").
- Repo contains dialog code and focus helpers in src/tui/components/dialogs.ts and related focus/navigation logic in src/tui/controller.ts and src/tui/dialog-focus.ts (see related-work below).
- Multiple prior work items addressed dialog focus/key issues and helper refactors (some completed, some in-progress).
Desired change:
- Audit the dialog key handling and focus wiring for Create and Update dialogs and ensure textarea widgets consume printable key events while focused (prevent propagation to global app keybindings).
- Fix the specific cause (e.g. duplicated/global key handler not gated by dialog open state OR textarea not registering/consuming key events correctly).
- Add unit/integration tests reproducing the original failure and validating the fix.
- Update documentation and add a short changelog entry.
Related work (automated report):
- src/tui/components/dialogs.ts — DialogsComponent: construction and wiring of Create/Update dialog widgets; a primary place to inspect textarea and key handlers.
- src/tui/controller.ts — Dialog focus and global keybinding coordination; contains comments noting guarding global handlers when dialogs are open.
- src/tui/components/update-dialog-README.md — Documented keyboard expectations for the Update dialog (Escape, Enter, Ctrl+S behavior). Use as reference.
Potentially related work items:
- Investigate and fix update dialog keypress handling (WL-0MLFU22T40EW892X) — Completed; fixed triple keypress regression in update dialog; inspect the fix and tests for patterns.
- Refactor dialog focus & field navigation into shared helper (WL-0MNX4D3Y20072XLI) — Completed; provides shared focus wiring that may influence where to patch the bug.
- Create shared dialog-helpers module (WL-0MO5SBA2C0011DXJ) — In-progress; ongoing refactor of dialog widget creation.
- Migrate DialogsComponent to use helpers (WL-0MO5SBPQW006ZZ3Q) — Blocked; relevant when touching widget construction.
- Dialog key propagation bugs (WL-0MO5XN3WK005CDS7) — Completed; contains historical context on key propagation fixes.
Appendix: Clarifying questions & answers
- Q: "Do you confirm WL-0MO6ZDLJ5001JUQN is the authoritative work item for this intake?" — Answer (agent inference): Yes; the provided id exists and was updated to in-progress. Source: wl update output. Final: yes.
- Q: "Were any clarifying questions required to prepare this draft?" — Answer (agent): No further clarifying questions were necessary; the existing work item description and repository context provided sufficient detail. Source: agent inference and repo inspection. Final: no clarifying questions.
Notes:
- If investigation reveals the root cause is a shared helper or broad refactor is required, record that as a child work item (do not expand scope of this intake).
Problem statement:
In Create and Update modal dialogs the 'x' keypress (and potentially other keys) is being handled by the application-level keybindings and closes the dialog instead of being inserted into multi-line textarea widgets, preventing users from typing these characters.
Users:
Example user stories:
Success criteria:
Constraints:
Existing state:
Desired change:
Related work (automated report):
Potentially related work items:
Appendix: Clarifying questions & answers
Notes: