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.
ruslan