[Select] First option chosen as selected when grouping with ListSubheader

[norayr93]

Duplicates

• I have searched the existing issues

Latest version

• I have tested the latest version

Steps to reproduce 🕹

https://codesandbox.io/s/eloquent-architecture-in71n1 - It's a simple grouping.

Current behavior 😯

Select chooses the first option as selected when using grouping with ListSubheader and the initial value is an empty string.

Expected behavior 🤔

Select doesn't have a selected option when the value is an empty string.It's also stated in the docs.

The input value. Providing an empty string will select no options. Set to an empty string '' if you don't want any of the available options to be selected.

Context 🔦

I have also posted the issue on StackOverflow

Your environment 🌎

npx @mui/envinfo

  System:
    OS: macOS 12.0.1
  Binaries:
    Node: 16.13.0 - ~/.nvm/versions/node/v16.13.0/bin/node
    Yarn: 1.22.17 - ~/.nvm/versions/node/v16.13.0/bin/yarn
    npm: 8.1.0 - ~/.nvm/versions/node/v16.13.0/bin/npm
  Browsers:
    Chrome: 106.0.5249.103
    Edge: Not Found
    Firefox: 104.0.2
    Safari: 15.1
  npmPackages:
    @emotion/react: ^11.9.0 => 11.9.3 
    @emotion/styled: ^11.8.1 => 11.9.3 
    @mui/base:  5.0.0-alpha.101 
    @mui/core-downloads-tracker:  5.10.9 
    @mui/icons-material: ^5.6.2 => 5.8.4 
    @mui/material: ^5.10.9 => 5.10.9 
    @mui/private-theming:  5.10.9 
    @mui/styled-engine:  5.10.8 
    @mui/system:  5.10.9 
    @mui/types:  7.2.0 
    @mui/utils:  5.10.9 
    @types/react: ^18.0.5 => 18.0.14 
    react: ^18.0.0 => 18.2.0 
    react-dom: ^18.0.0 => 18.2.0 
    styled-components: ^5.2.1 => 5.3.5 
    typescript: ^4.6.3 => 4.7.4 

[mnajdova]

This is a regression introduced in #27299. We should not add the item as selected. cc @michaldudak could you verify that the linked PR was indeed wrong? In my opinion, we should have just focused that element.

[michaldudak]

Yes, it seems that it's incorrectly selecting the first element in this case. Unfortunately, the tests did not cover this scenario. @norayr93 would you like to contribute to the project by working on a fix?

[nzayatz14]

Unsure if this is related but I believe this issue also occurs when the Select component is in Multi-select mode

[litera]

@michaldudak: Mind that this is bug, because the mentioned regression selected the first selectable item to enable keyboard interaction with the Select component. That PR definitely wasn't adequate and shouldn't be approved in the first place.

The Select doesn't even need to use ListSubheader components. It presents the bug even when the first MenuItem option is disabled. This is an example of a super simple select that has the bug, and the second one that mitigates it. Mind that second one, that has no selected items has no keyboard interaction either.

I've created a new issue related to this bug just yesterday (#36018), which is a duplicate of this one, but has a lot more information in the description pointing to erroneous code directly.

[litera]

Unsure if this is related but I believe this issue also occurs when the Select component is in Multi-select mode

No. Multi select should work fine, because empty array (no items selected) is not falsey.

const isFirstSelectableElement = () => {
  if (value) { // <=== THIS prevents the bug in multi-select mode
    return selected;
  }
  const firstSelectableElement = arr.find(
    (item) => item?.props?.value !== undefined && item.props.disabled !== true,
  );
  if (child === firstSelectableElement) {
    return true;
  }
  return selected;
};