Addon config multi-select chip inputs show an empty suggestion list

[kingpanther13]

Checklist:

• I have checked that this issue has not already been reported.
• I have checked that this issue has not already been fixed.
• I am running the latest version of Home Assistant.
• I have cleared my browser cache.
• I have tried in a different browser.

Description:

When an addon's configuration page has a field that lets you add multiple items (like the Samba addon's "Enabled shares" field), the input box says "Search | add custom item" and shows a dropdown area when you click it — but the dropdown is always empty. There are no suggestions to pick from. You have to already know the exact valid values and type them in manually. If you type something wrong, you don't find out until you click Save, and then you get a regex error message.

Meanwhile, the exact same looking input box is used elsewhere in Home Assistant (for example, when editing an automation's entity state trigger, the "Attribute" field). In those other places, the dropdown actually shows suggestions you can pick from.

The issue is that addon configuration pages can't provide a list of suggested values to populate that dropdown, even though the widget clearly supports it. This makes the Samba-style multi-select field a bad UX — users have to go find the list of valid values somewhere else (docs, forum, README) and type them in from memory.

Expected behavior:

When an addon schema declares a multi-value field with a known set of allowed values, the dropdown should show those values as selectable suggestions, the same way it works in the automation entity attribute picker.

Steps to reproduce:

1. Open the Samba addon (or any addon with a [match(...)] or [str] schema field)
2. Go to the Configuration tab
3. Click on the "Enabled shares" (or equivalent multi-value) field
4. Observe that the dropdown area is empty — no suggestions appear even though there's a fixed list of valid values (addons, addon_configs, backup, config, media, share, ssl)
5. Now compare this to creating a new automation, choose an entity state trigger, pick an entity, and click on the "Attribute" field — the dropdown shows all the entity's attributes as suggestions

Home Assistant Core version: latest

Browser: Any

---

⚠️ Warning: the following section is AI-generated. The above description is my own words. Below is what an AI thinks the problem is and how to fix it — I have not personally verified every line of code referenced here, but the analysis looks sound and is offered as a starting point for whoever works on the fix.

AI-generated analysis and proposed fix

The relevant code is in src/panels/config/apps/app-view/config/supervisor-app-config.ts in the _convertSchemaElementToSelector method.

The Supervisor backend does the right thing: for a schema like protocols: [list(http|https|mqtt|ws)], supervisor/addons/options.py in the _single_ui_option / _ui_schema_element chain correctly emits a UI node with type: "select", options: [http, https, mqtt, ws], and multiple: true.

The frontend converter then does this:

if (entry.type === "select") {
  return { select: { options: entry.options } };  // <-- entry.multiple is dropped
}
if (entry.type === "string") {
  return entry.multiple
    ? { select: { options: [], multiple: true, custom_value: true } }
    : { text: { type: ... } };
}

Two separate problems in these lines:

1. The "select" branch drops entry.multiple. So [list(a|b|c)] renders as a single-select dropdown, not a multi-select chip input.
2. The "string" branch (which handles [str] and [match(regex)]) hard-codes options: []. So the multi-select chip input from those schemas has no suggestions to show, which is the Samba behavior described above.

The ha-selector-select widget fully supports {multiple: true, options: [...non-empty]} — it's what the automation attribute picker uses via ha-entity-attribute-picker → ha-generic-picker → ha-picker-combo-box. The widget works, but no code path from addon config constructs that shape.

Proposed fix (3 lines):

if (entry.type === "select") {
  return {
    select: {
      options: entry.options,
      multiple: entry.multiple,
    },
  };
}

This mirrors the entry.multiple handling already present in the "string" branch immediately below. With this fix, addon authors can use [list(a|b|c)] to get a proper multi-select chip input with populated suggestions — matching the automation attribute picker UX.

References that support this analysis:

• home-assistant/supervisor#6171 — merged supervisor PR that added deep nesting support and uses condition: list(equal|not_equal) as an example, confirming list(a|b|c) is an officially supported schema type
• home-assistant/developers.home-assistant#2778 — open docs PR actively documenting the list(a|b|c) syntax as a first-class schema type
• home-assistant/frontend#30121 — recent merged frontend PR that touched the same file and used list(MONO|BWR|BWY|...) in its own example