Browser password manager fills the saved local-login username into the SPA searchbox #625
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Dogfood find (Nikola, Edge): after saving the local login (
admin1) on/login, the browser populates the searchbox in the app with the saved username — which was the original trigger for the #602 stale-filter bug.Root cause (investigated 2026-09-18):
/login(web/static/login.html) is correctly annotated (autocomplete="username"/current-password), so the credential gets saved for the origin. But the inputs carry nonameattributes, so the save is bound only to weak field signals.index.htmlcontains#chpw-curwithautocomplete="current-password"(the change-password dialog — present in the DOM even while closed). Chromium/Edge classifies that as a sign-in password field and then runs its username-predecessor heuristic: pick a preceding fillable text control. The change-password dialog has no username field, so the walk escapes the dialog and lands on the first eligible text control on the page — the searchbox.autocomplete="off"does not help: Chromium's password manager deliberately ignores it for credential fills.Remediation (this issue):
#chpwdlggains a hiddenautocomplete="username"anchor field before#chpw-cur— the recommended change-password pattern; the password manager pairs with it and stops hunting. (Also improves credential-update behaviour on password change.)name="q"+role="searchbox"— the classifier weighs theqname token heavily as a search field, excluding it from username candidates.login.html(andsetup.html) inputs gainname="username"/name="password", strengthening the save-side classification.Defense in depth: since #602 (v0.6.225), any navigation clears the searchbox anyway, so even a mis-filled value can no longer silently filter listings — this issue removes the mis-fill itself.
Verification is manual by nature (browser heuristics): re-save the credential on /login, reload the app, confirm the searchbox stays empty.
Shipped in v0.6.226 (PR #626, tag on
f52c5a6), live on both dogfoods.All three remediations from the analysis are in: the hidden
autocomplete="username"anchor in the change-password dialog (the actual fix — the manager now pairs inside the dialog instead of hunting to the searchbox),name="q"+role="searchbox"on the searchbox, andnameattributes on the login/setup credential inputs.Needs your manual verification, Nikola (browser heuristics can't be unit-tested): on files-bao in Edge, sign out → sign in as
admin1locally → let Edge re-save the credential → reload the app → the searchbox should stay empty. If Edge still offers/fills the old saved entry, delete the stored credential for the site once and re-save (the old entry was recorded against the weakly-identified fields). Leaving the issue open until your check confirms; close it if clean.Verified manually by Nikola in Edge: after re-saving the login credential and reloading, the browser no longer offers the stored username in the searchbox. The v0.6.226 remediation (hidden
autocomplete="username"anchor before the password field, searchboxname="q"+role="searchbox", explicit name attributes on login/setup) holds. Closing.