This problem is not solved by `keydown`

[greggman]

https://github.com/WICG/close-watcher/blob/4afb9eec1347e85a92251375f32c0aff953dfac0/README.md?plain=1#L50

I thought you might want to add another reason for this API. Make this dialog

<dialog>name: <input type="text"></dialog>

Write this code

const dialog = document.querySelector('dialog');
dialog.show();

window.addEventListener('keydown', e => {
  if (e.key === 'Escape') {
    dialog.close();
  }
});

Switch to Japanese input, click in the input box, type some Japanese, See the Input Method Editor appear, press Esc to close the Input Method Editor. See the Dialog box get closed even though that was not the user's intent.

This might also inform the API's design.

[domenic]

Nice! I updated https://close-watcher-demo.glitch.me/ with a textbox in the sidebar and confirmed that in Chrome Canary with experimental web platform features turned on, it behaves as expected---the first Esc key press closes out of the IME, and the second closes the sidebar.

[greggman]

I'd be curious to know what other keys are, possibly wrongly, passed to the page. AFAIK, at least in Chrome, all the keys are passed through even though those keys are manipulating the IME. This issue appears in Google Docs where you start typing Japanese, see the IME, use the cursor keys to move around which word you want to edit in the IME, Docs is still receiving the cursor keys and messes up.

It's great this API solves the Escape issue but it's not solving the general issue. Not sure that matters, just passing it on.