Skip to content

fix(app): preserve draft through permission prompts#22495

Open
terminalchai wants to merge 1 commit intoanomalyco:devfrom
terminalchai:fix/preserve-draft-permission-prompt
Open

fix(app): preserve draft through permission prompts#22495
terminalchai wants to merge 1 commit intoanomalyco:devfrom
terminalchai:fix/preserve-draft-permission-prompt

Conversation

@terminalchai
Copy link
Copy Markdown

Issue for this PR

Closes #21320

Type of change

  • Bug fix

What does this PR do?

When a permission prompt blocks the session composer, the PromptInput was conditionally unmounted via <Show when={!blocked()}>. Unmounting destroys component state, so any text the user had typed before the prompt appeared (or typed thinking focus was still in the input) was silently discarded when the prompt resolved.

The fix replaces the conditional <Show> with a persistent wrapper <div> that keeps PromptInput mounted at all times. When the session is blocked the wrapper receives the hidden Tailwind class (display:none) and aria-hidden="true", so it is invisible and inaccessible to assistive technology — but the component instance and its internal draft state are preserved. When the block clears both attributes are removed and the input reappears with the draft intact.

How did you verify your code works?

  • bun x prettier --write src/pages/session/composer/session-composer-region.tsx e2e/session/session-composer-dock.spec.ts (from packages/app)
  • bun run test:e2e -- session/session-composer-dock.spec.ts -g "blocked permission flow preserves typed draft" and -g "keyboard focus stays off prompt while blocked" (from packages/app)

Two new e2e specs cover the regression:

  1. blocked permission flow preserves typed draft — types into the composer, triggers a permission prompt, accepts it, and asserts the original text is still present in the input.
  2. keyboard focus stays off prompt while blocked — asserts the composer input is not focusable (aria-hidden / display:none) while the prompt is active.

Screenshots / recordings

No visual change in normal usage. The composer looks and behaves identically; draft text simply survives permission prompts now.

Checklist

  • I have tested my changes locally
  • I have not included unrelated changes in this PR

@github-actions
Copy link
Copy Markdown
Contributor

The following comment was made by an LLM, it may be inaccurate:

Potential Duplicate Found:

Why they may be related: Both PRs address the same core issue - preserving draft text when permission prompts appear in the composer. The titles and scope are virtually identical, addressing issue #21320. You should verify the status of PR #21950 (whether it's open/closed/merged) and consolidate efforts if both are active.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[BUG] Input text typed during a pending permission prompt is lost after accepting/rejecting

1 participant