[PM-41319] fix: Autofill phone-number login credentials via fill-assist

[aj-rosado]

🎟️ Tracking

https://bitwarden.atlassian.net/browse/PM-41319

📔 Objective

Fill-assist wasn't autofilling phone-number login credentials on sites where a single field accepts either a phone number or an email address (declared under both "email" and "phone" keys in the same host rule).

Two separate bugs combined to cause this:

• toAutofillViewForFieldKey had no case for the "phone" field key, so a matching selector silently produced no view at all.
• When a field matched both "email" and "phone", the resolution picked whichever key happened to be listed first in the rules JSON. Since "email" was typically listed first, dual-purpose fields resolved to Login.Email, whose fill logic gates on isValidEmail() — silently rejecting phone-number credentials on a field that would have accepted them.

Fix:

• Map "phone" to Login.Username, which has no format gate (matches existing heuristic-mode behavior for phone-hinted fields).
• When a field matches multiple keys, explicitly prefer Login.Username over other candidate types rather than relying on map ordering.
• Trim the stored username only for the isValidEmail() check itself (not the filled value) so incidental leading/trailing whitespace on an otherwise-valid email doesn't silently block the fill.

No UI changes.

[github-actions]

🤖 Bitwarden Claude Code Review

Overall Assessment: APPROVE

Reviewed the fill-assist changes in FillAssistViewNodeExtensions.kt (new "phone" field key mapping to Login.Username, and explicit Login.Username preference when a node matches multiple field keys) and the isValidEmail() trim in FilledDataBuilderImpl.kt. Traced the downstream impact through AutofillParserImpl.toEffectiveViews, partition construction (filterIsInstance<AutofillView.Login> / <AutofillView.Card>), and the save-value extraction in AutofillPartitionExtensions.kt; card partitions and save prompts are unaffected by the new preference. The "phone" → Login.Username mapping is consistent with heuristic-mode behavior, where "phone" is already in SUPPORTED_RAW_USERNAME_HINTS. Test coverage was added for the new phone key, the multi-key preference, the combined phone-or-email case, and the whitespace-tolerant email gate.

Code Review Details

No findings met the confidence threshold for posting. Notes considered and dropped during validation:

• The filled value for Login.Email remains untrimmed while only the isValidEmail() gate is trimmed — explicitly documented as intentional in the PR description, asserted by the new test, and consistent with the untrimmed Login.Username path.
• Codecov reports 0% patch coverage on the 6 changed lines, but both changed files have corresponding new tests in FillAssistViewNodeExtensionsTest.kt and FilledDataBuilderTest.kt; this appears to be a coverage-reporting artifact rather than a gap.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 85.83%. Comparing base (32c2e8a) to head (57cb25a).
⚠️ Report is 1 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #7250      +/-   ##
==========================================
- Coverage   86.11%   85.83%   -0.29%     
==========================================
  Files         894      937      +43     
  Lines       65210    66992    +1782     
  Branches     9756     9798      +42     
==========================================
+ Hits        56155    57500    +1345     
- Misses       5560     5985     +425     
- Partials     3495     3507      +12     

Flag	Coverage Δ
app-data	17.46% <100.00%> (-0.35%)	⬇️
app-ui-auth-tools	18.65% <0.00%> (-0.03%)	⬇️
app-ui-platform	16.93% <0.00%> (+0.47%)	⬆️
app-ui-vault	27.92% <0.00%> (+0.52%)	⬆️
authenticator	6.09% <0.00%> (+0.01%)	⬆️
lib-core-network-bridge	4.09% <0.00%> (-0.01%)	⬇️
lib-data-ui	1.20% <0.00%> (-0.01%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[andrebispo5]

having the trim here will create the valid email but will pass along the spaces it removes to the autofill value.

[aj-rosado]

This was something extra ticket that I noticed while testing (my email for a field had an empty space so it was not being identified as an email by our function)

Did not want to modify the value autofilled to keep it as it is saved. If it is not intentional the user might notice and fix it.