command palette input doesn't allow some keys

[Presskopp]

In the input field of the command palette ("Search commands and settings") keys like 'ArrowDown', 'ArrowUp', 'Home', 'End' are restricted, why?

See commands.js, ~L. 3150

case "ArrowDown": {
  ie(e);
  break;
}
...
case "ArrowUp": {
  se(e);
  break;
}
case "Home": {
  e.preventDefault(), X2(0);
  break;
}
case "End": {
  e.preventDefault(), oe();
  break;
}

can we set them free?

[abcd95]

I see this behavior too, in command palette search, Home/End, and arrow keys are being captured by palette navigation, so native input caret behavior is limited.

This looks partly intentional for result navigation, but likely too aggressive in the textbox context. I think we should further discuss this on expected key ownership (input vs list) before patching. Also, can address this ​here for a proper discussion.

[Presskopp]

see: ​https://www.w3.org/WAI/ARIA/apg/patterns/combobox/

[wildworks]

@Presskopp Thanks for the report, but can you clarify what the actual problem is and what the ideal behavior should be?

See commands.js, ~L. 3150

This code likely doesn't exist within WordPress or Gutenberg itself, but rather in the cmdk library that the command palette depends on.

​https://github.com/dip/cmdk/blob/dd2250ed608443e8f32bafc5fa2d1d07a3746aa3/cmdk/src/index.tsx#L592-L637

[Presskopp]

To clarify:

The Home/End keys should take me to the beginning/end of the string in the input field, or to make it short:
The input field should behave like any other usual input field, as long as it has focus.

quoting
​https://www.w3.org/WAI/ARIA/apg/patterns/combobox/examples/combobox-autocomplete-list

An HTML input with type="text" is used for the textbox so the browser will provide platform-specific editing keys.

quoting
​https://www.w3.org/WAI/ARIA/apg/patterns/combobox/

When a descendant of a listbox, grid, or tree popup is focused, DOM focus remains on the combobox and the combobox has aria-activedescendant set to a value that refers to the focused element within the popup.

[Presskopp]

there's already an upstream issue regarding the key binding: ​https://github.com/dip/cmdk/issues/379

[wildworks]

Thanks for clarifying the problem. This issue seems to need fixing upstream. I'm not sure if we can override that behavior in the @wordpress/commands package.

[joedolson]

There are related issues with cmdk in ​https://github.com/WordPress/gutenberg/issues/50846.

Is there anything we can address here directly, @wildworks? If not, we should close this as reported upstream. But knowing that there are several issues with cmdk, I'd like to try and address anything we can, or take a more active role in trying to get changes made upstream.

It doesn't seem like there's been any movement on the upstream issues raised in the past; if we're going to depend on it, we should possibly take a more active role in trying to get fixes made.

[wildworks]

Perhaps the best course of action would be to completely move away from cmdk. I propose closing this ticket and continuing the discussion in Gutenberg.

​https://github.com/WordPress/gutenberg/issues/76950

[joedolson]

I think closing this ticket and focusing on the upstream ticket makes sense. Practically speaking, none of the work on this is primarily core work, so the only resolution is "reported upstream", anyway.