Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

This problem is not solved by keydown #29

Open
greggman opened this issue Oct 2, 2023 · 2 comments
Open

This problem is not solved by keydown #29

greggman opened this issue Oct 2, 2023 · 2 comments

Comments

@greggman
Copy link

greggman commented Oct 2, 2023

On desktop platforms, this problem is currently solved by listening for the `keydown` event, and closing the component when the <kbd>Esc</kbd> key is pressed. Built-in platform APIs, such as [`<dialog>`](https://developer.mozilla.org/en-US/docs/Web/API/HTMLDialogElement/showModal), [fullscreen](https://developer.mozilla.org/en-US/docs/Web/API/Fullscreen_API), or [`<input type="date">`](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/date), will do this automatically. Note that this can be easy to get wrong, e.g. by accidentally listening for `keyup` or `keypress`.

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
Copy link
Collaborator

domenic commented Oct 3, 2023

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
Copy link
Author

greggman commented Oct 3, 2023

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.

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

No branches or pull requests

2 participants