- Fill username by specific attrs even without visible password field
(handles two-step forms: username first, password appears after)
- Broad input[type=text] fallback only fires when password field is present
(prevents filling R7-Office font selector and other app inputs)
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Prevents autofill from filling app text inputs (e.g. R7 font selector)
after login. Now tryFill() bails out immediately if no input[type=password]
is visible — meaning we are no longer on a login form.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
- Credentials wrapped in svc-credentials-wrap with toggle button and chevron
- Credentials hidden by default, expand on click (CSS class toggle)
- Autofill: add autofocus selector to catch fields like Zabbix name=name
- Autofill: re-fill username after password fill if Pult/Zabbix cleared it
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
- Add --disable-features=PasswordManagerEnabled to Chromium flags
- Add credentials_enable_service=False and profile.password_manager_enabled=False to Chrome Preferences
- Install chromium-l10n package in Dockerfile for Russian browser UI
- Split filled flag into userFilled/passFilled for independent tracking
- Add findUserFieldNearPassword() for DOM-relative lookup near password field
- Add isVisible() helper to skip disabled/hidden/offscreen inputs
- Add console.log tracing for debugging
- Add background.js service worker with webRequest.onAuthRequired for Basic Auth
- Add _url_with_credentials() to embed login:pass in URL for HTTP Basic Auth
- Use /usr/lib/chromium/chromium binary directly (bypass Debian wrapper)
- Add --enable-logging=stderr for console.log capture in chromium logs
The previous approach pre-populated Chromiums Login Data SQLite with
schema version 30 and AES-128-CBC v10 encrypted passwords. Chromium 147
expects schema version 43, fails to migrate (Unable to migrate database
from 30 to 43), and refuses to open Login Data altogether. Result: the
row was written but Chromium never read it, so autofill never worked.
Instead generate a tiny Manifest V3 extension per session in a temp dir
with a content_script that finds username and password fields, sets
their values, and dispatches input/change events. Pass it via
--load-extension and --disable-extensions-except so it is the only
extension loaded.
Benefits:
- Independent of Chromium version and Login Database schema
- Works on SPAs (MutationObserver re-runs on DOM changes)
- Credentials live only in a temp file alongside the profile, removed
on session end via _stop_current
- No SQLite or cryptography dependency
- Removes the silent failure mode of Login Data migration
Removes _chrome_encrypt_v10, sqlite3, hashlib, urlparse imports.
Adds _create_autofill_extension and tracks extension_dir alongside
profile_dir in _state for cleanup symmetry.
- universal-runtime: set _state[profile_dir] AFTER _start_process so
_stop_current does not delete the freshly-created profile before
Chromium reads it. Without this, Login Data was being wiped.
- rdp-proxy: add xdotool dependency and background anti_idle_loop that
sends Shift to the xfreerdp window every 30s, forwarded over RDP to
reset the remote idle timer and keep the lock screen from kicking in.