Escape does not close an open dialog

[XDLCS]

Summary

A open <dialog> (opened via the open attribute or show()) does not close on Escape. The key event reaches the page — a keydown listener observes key: "Escape" — but the dialog's built-in light-dismiss never runs, so dialog.open stays true.

Note: commit 2ddb4f7 ("fix(dialog): enforce show state transitions", 2026-08-29) landed after this was first observed; the Escape path is still not covered by it. This report reflects behavior after that fix.

Environment

• moli 1.0.6, also verified on local build a1385e0 (includes 2ddb4f7)
• Chromium baseline: chrome-headless-shell 131.0.6778.204, same CDP script

Reproduction (CDP)

Page:

<dialog id="d" open><p>x</p></dialog>
<script>document.addEventListener("keydown", e => { window.__k = e.key; });</script>

CDP: Input.dispatchKeyEvent keyDown Escape (key/code Escape, windowsVirtualKeyCode 27) then keyUp, wait 500ms.

Observed (moli)

{"open": true, "key": "Escape"}

The event listener fires (key reaches the document), but the dialog remains open. No cancel/close events, no light-dismiss.

Expected (Chromium 131)

Escape on an open dialog → cancel event → dialog closes (open: false), per the dialog light-dismiss spec.

Impact

Keyboard interaction model is incomplete: any page relying on Esc-to-close (modals, settings panels, autocomplete popups) cannot be dismissed via keyboard in moli — a standard agent keyboard-driving scenario.

Verified on a1385e0 (post-2ddb4f7): open:true, key:"Escape" — unchanged.

[BibekPathak]

Hi @ldm0 are you doing this or should i pick this up??

[ldm0]

@BibekPathak Feel free to work on it~

[qingqing-xiaowen]

Hi @XDLCS, thank you for the exceptionally careful compatibility reports you’ve been filing for Moli.

In #284, your comparison between Moli 1.0.6/local build a1385e0 and Chromium 131 using the same CDP Escape sequence made the behavior especially clear: the keydown reached the page, but no cancel or close event followed and the dialog remained open.

Looking across your reports on dialogs, network APIs, PDF and rendering behavior—as well as your merged Windows-related contributions—it looks like you’ve been evaluating Moli much more systematically than through isolated smoke tests.

Would you be open to telling us more about the real workflow behind this evaluation—what kind of agent or browser-compatibility tasks you’re trying to support, where Moli currently blocks those tasks, and which gaps matter most to you? For #284 specifically, it would also help us understand whether the workflow depended on modal showModal() behavior or non-modal show()/open behavior, and what the agent needed to do next after pressing Escape.

We’re very happy to continue in writing here on GitHub. If email or another online channel is easier, that works too. There’s nothing to prepare and no meeting is required; voice or video is entirely optional.

We’ll make sure anything you share is brought back to the team as product input. If there’s relevant progress we can share later, we’ll do our best to update you here as well. Even a short reply would be helpful, and no worries at all if now isn’t a good time.