[GH-ISSUE #288] bug: login screen never autofills on mobile password managers (CSR-only auth form) #201

New issue

Open

opened 2026-10-18 14:03:45 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-10-18 14:03:45 +00:00

Owner

Originally created by @Classic298 on GitHub (Sep 20, 2026).
Original GitHub issue: https://github.com/open-webui/computer/issues/288

The login screen renders client-side only. The server sends a ~2KB empty shell for every page (no <form>, no <input> anywhere in the HTML), and the auth form only exists in the DOM after: JS loads, SvelteKit hydrates, an auth-state check round-trips, and only then does the login screen mount.

Password-manager browser extensions watch for DOM changes, so on desktop they eventually see the form and offer autofill. Mobile autofill services (Android Autofill API, Bitwarden, 1Password, KeePassDX) scan the page when it loads, find zero password fields, and give up — re-scanning on late client-side mount is not something they do reliably. The result on mobile is "no password fields detected" and no autofill ever.

Two aggravators in the auth screen itself:

the username and password inputs have autocomplete tokens (username, current-password/new-password) but no name and no id attribute; several password managers key their field matching on those
the form mounts only after the async session check completes, adding further delay before any field exists to scan

Suggested fix, in increasing effort:

Add name="username" / name="password" (and matching ids) to the inputs. Cheap, helps some matchers, does not fix the CSR race.
After the auth screen mounts, explicitly re-trigger autofill (dispatch a focus event on the username field, or use the WebOTP/requestAutocomplete-style hints where available). Mitigates the race for managers that re-scan on interaction.
Server-render the auth screen (SSR just the login route, or at least the form markup). This is the real fix: the HTML response for a logged-out visitor contains the form, so every autofill service, mobile included, sees the fields on first scan.

Repro: curl the root URL of a running instance while logged out, observe there is no form in the HTML; open the same URL in Bitwarden on Android, get no autofill offer.

Originally created by @Classic298 on GitHub (Sep 20, 2026). Original GitHub issue: https://github.com/open-webui/computer/issues/288 The login screen renders client-side only. The server sends a ~2KB empty shell for every page (no `<form>`, no `<input>` anywhere in the HTML), and the auth form only exists in the DOM after: JS loads, SvelteKit hydrates, an auth-state check round-trips, and only then does the login screen mount. Password-manager browser extensions watch for DOM changes, so on desktop they eventually see the form and offer autofill. Mobile autofill services (Android Autofill API, Bitwarden, 1Password, KeePassDX) scan the page when it loads, find zero password fields, and give up — re-scanning on late client-side mount is not something they do reliably. The result on mobile is "no password fields detected" and no autofill ever. Two aggravators in the auth screen itself: - the username and password inputs have `autocomplete` tokens (`username`, `current-password`/`new-password`) but no `name` and no `id` attribute; several password managers key their field matching on those - the form mounts only after the async session check completes, adding further delay before any field exists to scan Suggested fix, in increasing effort: 1. Add `name="username"` / `name="password"` (and matching `id`s) to the inputs. Cheap, helps some matchers, does not fix the CSR race. 2. After the auth screen mounts, explicitly re-trigger autofill (dispatch a focus event on the username field, or use the WebOTP/`requestAutocomplete`-style hints where available). Mitigates the race for managers that re-scan on interaction. 3. Server-render the auth screen (SSR just the login route, or at least the form markup). This is the real fix: the HTML response for a logged-out visitor contains the form, so every autofill service, mobile included, sees the fields on first scan. Repro: curl the root URL of a running instance while logged out, observe there is no form in the HTML; open the same URL in Bitwarden on Android, get no autofill offer.

No labels

enhancement

pull-request

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

open-webui/computer#201

No description provided.

Rows
Columns