fix(modal): propagate body view keymap context so editor bindings work inside modals (#13067)

[ther12k]

Description

Modal-hosted text fields (e.g. the Add Custom Endpoint dialog, API key fields in agent settings) do not support Ctrl+V / Cmd+V paste, Ctrl+C / Cmd+C copy, or right-click context menu operations.

Root cause

The generic Modal<T> wrapper did not override the keymap_context method on its View impl. The default trait implementation returns only {"Modal"}, which means keybindings gated on identifiers from child views (e.g. id!("EditorView") for paste/copy/cut) can never match when an EditorView is focused inside a modal.

This affects both:

• Custom keybindings (CustomAction::Paste, CustomAction::Copy, CustomAction::Cut) — registered with id!("EditorView") & !id!("IMEOpen")
• Standard paste (StandardAction::Paste) — also gated on id!("EditorView")

Fix

Added a keymap_context override to Modal<T> that extends the modal's own context ("Modal") with the body view's context (e.g. "CustomEndpointModal", "EditorView", etc.). This preserves the modal's Escape-to-close binding (gated on "Modal") while also exposing child view identifiers for their keybindings.

fn keymap_context(&self, ctx: &AppContext) -> Context {
    let mut context = Self::default_keymap_context();
    context.extend(self.body.keymap_context(ctx));
    context
}

Testing

• cargo check -p warp_app passes
• Manual verification on Linux

Manual verification

1. Open Warp Settings → Agents / AI → Add Custom Endpoint
2. Type text into a field, select it, press Ctrl+C
3. Press Ctrl+V — text is pasted correctly
4. Right-click in a field — context menu shows Copy/Paste options

Screenshots / Videos

Before: Ctrl+V in endpoint name field inserts only the 'v' character
After: Ctrl+V pastes the full clipboard content

Tested on: Linux (X11/Wayland)

Linked Issue

• The linked issue is labeled ready-to-implement.

Closes #13067
Related: #7694

Changelog

CHANGELOG-BUG-FIX: Fixed paste and copy not working in settings modal text fields

[cla-bot]

Thank you for your pull request and welcome to our community. We require contributors to sign our Contributor License Agreement, and we don't seem to have the users @ther12k on file. In order for us to review and merge your code, each contributor must visit https://cla.warp.dev to read and agree to our CLA. Once you have done so, please comment @cla-bot check to trigger another check.

[oz-for-oss]

@ther12k

Every PR must be linked to a same-repo issue before Oz can review it.

This PR is linked to #13067, but no linked issue is marked ready-to-implement yet. Only repository maintainers apply that label, so please wait for a maintainer to mark the issue. Once it is marked, push a new commit or comment /oz-review to re-trigger review.

See the contribution guidelines for the full readiness model.

Powered by Oz

[oz-for-oss]

@ther12k

Every PR must be linked to a same-repo issue before Oz can review it.

This PR is linked to #13067, but no linked issue is marked ready-to-implement yet. Only repository maintainers apply that label, so please wait for a maintainer to mark the issue. Once it is marked, push a new commit or comment /oz-review to re-trigger review.

See the contribution guidelines for the full readiness model.

Powered by Oz

[ther12k]

Per CONTRIBUTING.md:

Bug fixes can go straight to a code PR once the report is reproducible or otherwise actionable; they do not require spec PRs.

This is a straightforward UI bug fix (paste/copy not working in modal text fields). The issue was initially auto-labeled ready-to-spec by Oz triage, but per the contribution guidelines, bug fixes bypass the spec flow and can proceed directly to a code PR.

Requesting ready-to-implement label so Oz can review. See also related issue #7694 for the same root cause in Warp Agent settings fields.