[material-ui][Select] Allow specifying which keydowns open the menu

[steven-cole-elliott]

Duplicates

• I have searched the existing issues

Summary

It would be nice if developers could specify which keydowns open the menu without having to take ownership of what SelectInput otherwise manages internally when its open state is uncontrolled in order to do so.

Examples

No response

Motivation

We are using Selects as filter fields on a typical index screen, and we have already trained our users on using a CMD/CTRL + Enter keyboard shortcut to submit the current set of filter values to perform a search.

When that keyboard shortcut is issued and a Select has focus and/or is the active element, however, its menu will be opened.

It is great that pressing Enter when a Select has focus and/or is the active element does open its menu, but in the CMD/CTRL + Enter case, it would be a preferable UX to have it remained closed.

It is worth mentioning that Autocomplete does not open its menu when CMD/CTRL + Enter is pressed when it has focus and/or is the active element.

On a more general note, there seemed to be several old, closed issues that discussed event propagation and/or the ability to compose default behavior of event handling into custom event handlers, but all of those seemed to be in the context of Autocomplete:

• [Autocomplete] Add ability to override/compose key down events in autocomplete #19887
• [Autocomplete] Add ability to override key down events handlers #23487
• [Autocomplete] Add option to disable handling of home/end #19500

Perhaps related was mui/mui-x#1403 specific to DataGrid that introduced the defaultMuiPrevented on events which I'm assuming eventually led to being able to disable the default behavior The motivations there may not be identical here, but it did seem to deal with allowing developers to override the default event handling in cases without having to completely opt out of it and write it themselves if there were still cases where they wanted the default event handling behavior.

I most certainly do not have the context that y'all have to make the best informed decision about how to best add something like this to the API, so take this suggestion purely as another way to explain what I'd like to be able to do. It seems like

material-ui/packages/mui-material/src/Select/SelectInput.js

Lines 309 to 325 in 0d93e4a

	const handleKeyDown = (event) => {
	if (!readOnly) {
	const validKeys = [
	' ',
	'ArrowUp',
	'ArrowDown',
	// The native select doesn't respond to enter on macOS, but it's recommended by
	// https://www.w3.org/WAI/ARIA/apg/patterns/combobox/examples/combobox-select-only/
	'Enter',
	];
	if (validKeys.indexOf(event.key) !== -1) {
	event.preventDefault();
	update(true, event);
	}
	}
	};

could start by accepting some prop that allowed developers to specify which keydown event conditions should open the menu without having to provide the onKeyDown prop such that the logic in SelectInput's internal handleKeyDown could still be called. I'm imagining something like the following being evaluated that would take the place of the validKeys inclusion check within handleKeyDown in the snippet above

// Type for new openOnKeyDown prop
type OpenOnKeyDown = (event: React.KeyboardEvent<HTMLDivElement>) => boolean;

// Example openOnKeyDown prop function that would keep the existing behavior but opt-out when CMD/CTRL + Enter was pressed
const openOnKeyDown: OpenOnKeyDown = (event) => {
    const validKeys = ['ArrowUp', 'ArrowDown', ' '];
  if (validKeys.indexOf(event.key) !== -1 || (event.key === "Enter" && !event.metaKey)) {
    return true;
  }
  return false;
}

Thank you for your consideration and your work on this project.

Search keywords:

[steven-cole-elliott]

Note that I changed the issue title and summary to be more pointed and specific about the functionality that is desired.

While composability of the default behavior that SelectInput implements via its internal handleKeyDown would be nice, that expands the scope of the actual problem I'm trying to solve, which is only wanting to control which keydowns open the menu without having to make the open state controlled.

[DiegoAndai]

Hey @steven-cole-elliott, thanks for the report!

I added the waiting for upvotes label so the community can vote for this new feature.