Since #1222, the internal Select input is rendered as:
<input
type="text"
role="combobox"
autocomplete="new-password"
/>
The autocomplete="new-password" value appears to cause password managers such as Bitwarden to treat the Select's search input as a password-related field.
As a result, focusing/searching inside a regular Select can display Bitwarden's password generator/autofill UI, even though the Select has nothing to do with authentication or passwords.
Reproduction
Using Ant Design with a searchable/multiple Select:
<Form.Item name="assigneeUserEmails">
<Select
mode="multiple"
showSearch={{ optionFilterProp: 'label' }}
options={[
{ value: 'john@example.com', label: 'John Doe' },
{ value: 'jane@example.com', label: 'Jane Doe' },
]}
/>
</Form.Item>
The resulting input contains:
<input
type="text"
role="combobox"
autocomplete="new-password"
/>
When the input is focused in Chrome with the Bitwarden browser extension installed, Bitwarden displays its password-related UI inside/next to the Select.
Expected behavior
A regular Select/combobox should not be identified by password managers as a password-related field.
Additional context
This appears to be a regression introduced by #1222
I understand that autocomplete="new-password" was introduced there to preserve the Chromium autocomplete workaround after changing the input from type="search" to type="text".
However, new-password has password-specific semantics and can therefore be interpreted by password managers as an indication that the field is related to password creation.
Would it be possible to suppress Chromium autocomplete without using a password-specific autocomplete value?
Since #1222, the internal Select input is rendered as:
The
autocomplete="new-password"value appears to cause password managers such as Bitwarden to treat the Select's search input as a password-related field.As a result, focusing/searching inside a regular Select can display Bitwarden's password generator/autofill UI, even though the Select has nothing to do with authentication or passwords.
Reproduction
Using Ant Design with a searchable/multiple Select:
The resulting input contains:
When the input is focused in Chrome with the Bitwarden browser extension installed, Bitwarden displays its password-related UI inside/next to the Select.
Expected behavior
A regular Select/combobox should not be identified by password managers as a password-related field.
Additional context
This appears to be a regression introduced by #1222
I understand that
autocomplete="new-password"was introduced there to preserve the Chromium autocomplete workaround after changing the input from type="search" to type="text".However, new-password has password-specific semantics and can therefore be interpreted by password managers as an indication that the field is related to password creation.
Would it be possible to suppress Chromium autocomplete without using a password-specific autocomplete value?