🎟️ Tracking

Community feature request (52 replies, ~1.3k views): https://community.bitwarden.com/t/inline-autofill-menu-ability-to-filter-items-by-typing-searching/63417

📔 Objective

When the inline autofill menu is open and the user starts typing in a username/email field, the menu closes today (see triggerFormFieldInput -> closeAutofillInlineMenu). For users with several saved logins on the same site this means scrolling instead of narrowing. This PR keeps the menu open on login text fields and filters the cipher list using the typed text. The focused input field itself acts as the search box, so no new UI is added.

Behavior on password, TOTP, card, and identity fields is preserved unchanged (still close-on-type). The filter is reset whenever the inline menu closes, focus moves to a different field, or the vault refreshes, and it is treated as PII (never logged, length-capped).

Changes:

• autofill-overlay-content.service.ts: triggerFormFieldInput branches on inlineMenuFillType. For login text-like fields (CipherType.Login, InlineMenuFillTypes.AccountCreationUsername, excluding password/TOTP) it sends a new updateAutofillInlineMenuFilter message and keeps the menu open. All other field types use the existing close path bit-for-bit.
• overlay.background.ts: new inlineMenuFilter field, new updateAutofillInlineMenuFilter extension-message handler, and filter application via the existing SearchService.searchCiphersBasic before cipher projection. The filtered set flows through the existing updateAutofillInlineMenuListCiphers port message (no new ports).
• autofill-inline-menu-list.ts: accepts an optional filter and, when the resulting cipher list is empty, renders a localized "No matches for $FILTER$" empty state. The filter value is inserted as a text node so it cannot be interpreted as HTML.
• New i18n key inlineMenuNoMatches in _locales/en/messages.json.
• main.background.ts: passes SearchService to OverlayBackground (already initialized earlier in the DI graph).

No new permissions, no manifest changes, no new ports, no new event listeners. The implementation reuses existing plumbing that already works on Chrome, Firefox, and Safari. Ten new unit tests were added covering filter apply, reset on close/focus-change/vault refresh, non-searchable short-circuit, dedup, length cap, the iframe empty state, an XSS guard on the filter text-node insertion, and regression guards confirming password/card/identity still close on type. All 1766 autofill tests pass.

📸 Screenshots

Consolidation with PR #20543

After this PR was opened, we discovered that PR #20543 (Add filter-as-you-type to autofill inline menu, Gamerhund, opened 2026-05-07) already addresses the same feature and has been forwarded to internal teams by audreyality. To minimize churn and align with the prior art that is already in front of reviewers, this PR has been updated to:

Adopted from #20543 (their wire-protocol naming):

• Message command: filterInlineMenuCiphers (was updateAutofillInlineMenuFilter)
• Wire payload field: filterValue (was filter)

Retained from this PR (engineering differentials worth keeping):

• SearchService.searchCiphersBasic reuse instead of duplicating an inline lowercase-substring match. Picks up URI and notes matching for free and centralizes search logic.
• Field-type guard in triggerFormFieldInput: only login text fields (CipherType.Login, InlineMenuFillTypes.AccountCreationUsername, excluding password/TOTP) stream the filter. Password keystrokes never traverse the message bus. Card and identity fields keep their existing click-to-fill behavior.
• PII handling: filter value is length-capped, never logged, and explicitly documented as PII.
• Explicit reset hooks: filter resets on inline-menu close, focus-change to a different field, and full vault refresh.
• Localized "No matches" empty state in the iframe (new i18n key inlineMenuNoMatches), rendered with text nodes for XSS safety. Preferred over silently closing the menu on zero matches because it tells the user their query simply didn't match — backspacing restores the list without the menu disappearing and re-appearing.
• Regression-guard tests: explicit assertions that password / card / identity fields still close-on-type.

Deliberately not adopted from #20543:

• Auto-reopen on filter when the menu is closed. We treat an explicit close (Escape, blur, etc.) as user intent and do not re-open the menu just because the user typed another character. This may be revisited based on review feedback.
• Close-on-zero-matches. The localized empty state is the alternative chosen here.

If the team prefers #20543 as the basis, the wire-protocol naming now matches verbatim, so cherry-picking the differentials above is a small diff.