Modal focus can escape to the page, and one Escape closes nested dialog layers

[yinren112]

Modal focus can escape to the page, and one Escape closes nested dialog layers

Summary

The shared Web UI Modal exposes two related modal-stack problems:

1. keyboard focus is not contained by the active dialog, so Shift+Tab can move focus to controls behind it;
2. every mounted modal-like layer installs its own document-level keydown listener, so the same Escape event can close more than the topmost layer.

I reproduced both behaviors in the current Web UI at commit 47f9438.

Real reproduction

Environment: Windows 10, Chromium, local Web UI at http://127.0.0.1:3080, source checkout at 47f9438.

1. Open Settings.
2. Select Agent presets.
3. Click Copy Standard to open the copy-preset modal above Settings.
4. The identifier input receives focus.
5. Press Shift+Tab once: focus moves to the copy modal's Close button.
6. Press Shift+Tab again: focus moves behind the modal to the Settings “close details” control.
7. Press Escape once.

Observed:

• focus reaches an interactive control behind the aria-modal="true" dialog;
• one Escape closes both the copy-preset modal and the Settings panel.

Expected:

• Tab / Shift+Tab stay within the topmost modal;
• Escape dismisses only the topmost modal;
• closing the modal restores focus to its opener.

Call chain

The copy-preset flow mounts the shared Modal inside the already-open Settings panel:

SettingsRoot
  -> SettingsPanel
     -> Agent presets section
        -> Copy Standard
           -> shared Modal (copy-preset dialog)

Two independent document listeners then receive the same bubbling keydown event:

• Modal.tsx#L44-L51 calls the child modal's onClose() for Escape;
• SettingsRoot.tsx#L49-L55 calls the Settings panel's onClose() for that same event.

The shared dialog declares aria-modal="true", but has no focus trap or focus restoration: Modal.tsx#L55-L85.

There is already an in-tree workaround documenting both assumptions in the directory picker: it manually makes the parent inert because “Modal has no focus trap” and guards the parent close because Escape reaches every mounted Modal listener: DirectoryBrowser.tsx#L743-L760.

Impact surface

This is a shared primitive rather than a copy-preset-only defect. The current tree has 14 production <Modal> call sites, including workspace creation/browsing, agent presets, model/settings flows, and other nested UI paths. Any modal whose parent remains mounted can expose background controls to keyboard or assistive-technology users. Any nested layer with its own global Escape handler can also consume the same key event.

The directory picker already carries local state and comments to compensate for this behavior, which is evidence that callers currently have to understand and defend against the primitive's modal-stack semantics.

Root cause

Modal visually renders a modal overlay, but interaction ownership is global and unscoped:

• Escape is observed on document, once per mounted instance;
• keyboard focus is not cycled inside the active dialog;
• the opener is not captured/restored;
• underlying UI is not made inert by the primitive.

As a result, visual stacking and keyboard/event ownership diverge.

Minimum fix boundary

The smallest root-cause boundary is the shared Modal, not each feature caller:

1. handle Escape on the dialog/overlay event path and stop propagation after the topmost modal claims it;
2. contain Tab / Shift+Tab within that dialog while open;
3. capture the active opener and restore it on close;
4. make the underlying application subtree inert while the portal is active, preserving prior inert state for nested dialogs.

The Settings shell is a separate hand-built role="dialog"; after the shared primitive is corrected, it should either adopt the same primitive or receive the same interaction semantics. The minimal patch should not add caller-specific guards to all 14 call sites—the directory picker workaround shows why that does not scale.

I am preparing a runnable patch in a personal fork as technical evidence, since this repository currently routes external contributions through Discussions rather than pull requests.

[DRAG0NM]

已定位根因：Web UI 的弹层没有统一的焦点与 Escape 协调：primitives Modal 与 Settings 面板（SettingsPanel）是两套独立实现，各自向 document 注册自己的 keydown 监听器（一个 Escape 事件会触发所有弹层的 onClose），且两者都没有任何焦点圈禁（无 Tab … 完整源码定位与修复方案见 #943 。

[yinren112]

Runnable technical evidence is now available in my fork: yinren112@34e7d16

Manual verification on the rebuilt Web UI: Shift+Tab wrapped from the dialog Close button to the last enabled control inside the dialog; one Escape closed only the child copy-preset modal; focus returned to the Copy Standard opener; the Settings panel remained open. The patch is intentionally limited to the shared Modal primitive (one source file, no new dependency).

[DRAG0NM]

感谢按方案 A 实现了补丁（共享 Modal 原语、单文件、无新依赖），且手动验证覆盖了 #943 的三个复现点（Shift+Tab 圈禁、单层 Escape、焦点恢复到触发按钮）——这正是报告描述的预期行为。非常漂亮的落地。