53 Commits

Include renames

Author	SHA1	Message	Date
jaap-jan	dbddbcd711	Hand the terminal the keyboard on connect, and take it back on lock ... After a successful connect the first keystrokes went to the shell's UI rather than the remote shell. The page's own term.focus() focuses the textarea inside the document, which does nothing while the window's keyboard focus is still on the Connect button, so the terminal had to be clicked before it would accept anything. The obvious guess about the fix — that reaching a native child window needs SetFocus through P/Invoke — is backwards, and measuring it first is what kept this small. NativeWebView overrides Focusable to true and its OnGotFocus calls the adapter's Focus(), which on Windows is ICoreWebView2Controller::MoveFocus(PROGRAMMATIC). So a plain Avalonia Terminal.Focus() really does move Win32 focus into WebView2. Measured in a standalone harness with no DodoSSH code, on the same 340,* grid as the shell, reporting GetFocus() and the page's own document.hasFocus() at each step: focus lands on the Chrome_WidgetWin_1 child and the page reports hasFocus: true. It is the return trip the package does not implement. OnLostFocus calls the adapter's ResignFocus(), and on Windows that method body is empty, so Avalonia's focus and Win32's diverge: after textBox.Focus() the focused element is the text box while the keyboard is still on WebView2 — a caret that silently receives nothing. Window.Activate() and Window.Focus() were both measured and neither recovers it, so the hand-back is a SetFocus on the top-level, in Views/NativeKeyboardFocus.cs. A real mouse click does recover it, because Avalonia's window sets focus on pointer input, which is why this is invisible to anyone who clicks before typing. That turned up a worse defect than the one being fixed, and it shipped in 0500e43. Collapsing the WebView does not release the keyboard: focus stays on the hidden holder — measured held by a window reporting visible=False — while Avalonia's focused element becomes (none). So a user who had clicked the terminal and then pressed Lock got an unlock screen that swallowed the passphrase. Locking now hands the keyboard back and focuses that box. Ctrl+Shift+F6 is the way out for someone using only a keyboard. It has to be handled in terminal.js and posted to the host as a web message, because once the child window owns Win32 focus Avalonia receives no key events and no KeyBinding could fire; the package also subscribes MoveFocusRequested and discards it, so there is no Tab-out to lean on. Not Escape, which vim alone rules out, and not a bare F6, which TUIs bind — Ctrl+Shift is the range terminal emulators conventionally keep for themselves and never forward to the remote. Verified rather than assumed: the posted string arrives verbatim in Body, and the chord reaches the page as F6 with both modifiers. Order matters and is now recorded. Focus() on a collapsed control is a measured no-op and is not replayed when it is revealed, so focus survives a lock/unlock cycle only because a session can be opened solely from an unlocked vault, which is what reveals the control in the first place. The view models still reference no view. VaultViewModel raises SessionOpened on the success path only, the shell forwards it as TerminalSessionOpened through the generated OnVaultChanged hook so unlock, lock and dispose all attach and detach in one place, and the view holds the whole focus policy. An event rather than a bound flag because connecting a second host while one is open has to move focus again, and no state change describes that. Three tests, and what they do not cover is the point. They cover the plumbing: focus is asked for once per session, a failed connect does not ask at all — a host-key prompt needs the keyboard on its own buttons — and locking stops the forwarding. They cannot cover the focus call, because headless Avalonia has no native window, so a headless test would focus correctly and confirm the wrong belief; that is measured in the harness and written down in docs instead. Dropping the forwarding fails two of them and dropping the detach fails one; deleting the raise outright does not compile, since the event would be unused. Reaching the connect path at all needed two new fakes. FakeRenderer attaches the way the real page does — fetch the served page, read back the token and socket URL the host substituted into it, then open the socket with both subprotocols — rather than being handed the token, so the part of the handshake that has been got wrong before stays under test. FakeSsh replaces a factory that would need a reachable sshd, which DodoSSH.Client.Ssh.Tests already covers against a container. The suite also never called workspace.Start(), so nothing served the page and no renderer could have attached. DllImport rather than the source-generated LibraryImport, which requires AllowUnsafeBlocks for the whole project. The signature is blittable so there is no marshalling stub to improve on, and turning unsafe code on across a client that handles key material to gain nothing is a poor trade. Correcting an earlier entry: docs/platform-flags.md described this as a focus-plumbing gap and offered "click inside the terminal first" as the workaround. Both true, and both stop short of the half that matters — focus crosses into the WebView readily and never comes back on its own, which is the same mechanism as the text boxes that mysteriously stopped accepting keystrokes in the airspace entry above it, not a separate fault.	2026-07-29 14:31:09 +02:00
jaap-jan	0500e43e02	Stop the terminal's WebView painting over the setup screens ... The shell layered its setup and unlock screens over the terminal, which does not work: NativeWebView attaches a real Win32 child HWND through NativeControlHost, and a child window composites above everything its parent paints regardless of visual-tree z-order. The cards rendered sliced at the terminal column's left edge; at the window's default width every one of their buttons fell inside the WebView's rectangle, so the flow could only be completed by keyboard, and a click in that region handed Win32 focus to WebView2 so the text boxes silently stopped accepting keystrokes. The WebView is now collapsed while the vault is not unlocked. The comment that previously forbade this — hiding it means never realising it — was wrong: NativeControlHost creates the native attachment on attach to the visual tree, never consulting layout or visibility, and NativeWebView replays a Source assigned before its adapter exists. A collapsed WebView still starts WebView2, loads the page and lets the renderer attach. Confirmed: 35 msedgewebview2 processes with the control collapsed. What the first connection after unlocking actually depends on is the existing await on WaitForRendererAsync, since the data plane drops frames when no renderer is attached. Also fixes the second visible defect: the default server URL was https://localhost:7217, the API's *second* launch profile, while the README, its appsettings and a plain `dotnet run` all use http://localhost:5233 — so nothing was listening, and an HTTPS client against a plaintext port reports "The SSL connection could not be established", which reads as a certificate problem. The default now matches, a missing scheme is rejected by name instead of parsing as scheme "localhost", and that specific TLS failure now suggests http://. Both new tests fail when the fixes are reverted. Corrections to claims I made earlier and should not have: - docs/platform-flags.md asserted the opposite of the mechanism above and cited an established msedgewebview2 connection as verification. That observation was taken while the overlay was showing but, because of this very bug, the WebView was uncovered and in plain view — so it confirmed only that a visible WebView is realised. A process-level check cannot verify a rendering claim. The entry was also filed under "Local cache". - ITerminalHost was documented as the live seam the app plugs into, with a stub standing in for headless tests. It has no implementation anywhere and no test uses it; the view navigates the control directly. It also counted Avalonia.Controls.WebView and NativeWebView as two interchangeable backends when they are one component, with the Linux backend backwards. - The README claimed the shell's whole path was covered by tests. Its state machine is; its layout is covered by nothing, and a headless test could not have caught this — headless has no native window, so it would have rendered correctly and confirmed the wrong belief. Verified by screenshotting the running app: the card renders complete and centred at the default size, with the button clickable.	2026-07-29 13:26:30 +02:00
jaap-jan	49f617b450	Wire the Avalonia shell to the vault ... The host list now comes from the vault instead of from a form. A fresh machine takes a server URL, signs in through the browser, enrolls, and from then on opens with the passphrase alone. DodoSSH.Client.Session is the composition layer: where a profile lives, how it unlocks, and how a machine gets one. ClientPaths picks a non-roaming per-OS directory — %LOCALAPPDATA% and never %APPDATA%, because a SQLite cache that roams between two machines is a corrupt one, and each machine's outbox is its own. SessionOpener needs no transport at all and could not reach one if it wanted to; that is the offline unlock, asserted rather than asserted about. A wrong passphrase, a stale KDF and a grant revoked by a rekey are three different answers, because the remedies are three different things and telling someone to retype a passphrase that was never the problem is worse than saying nothing. The shell's states are the onboarding story. The recovery code gets its own state that cannot be clicked past: it exists for one moment, losing it with the passphrase loses the vault, and there is no server-side reset by design. It is dropped from memory on confirmation rather than merely hidden. Sign-in is a delegate over IVaultServer, so the whole state machine runs in a test against an in-memory server — no browser, no identity provider, no toolkit. The view models are plain observable objects, which is what makes that possible. What it does not cover is whether the XAML binds to the right names; that needs a rendered tree and Avalonia.Headless, and is its own piece of work. Three things found by doing it rather than by reading it: - Pooled SQLite connections keep the database file open after the last context is disposed. On Windows that means locked, so the application could never replace its own cache — and a test could not clean up after itself, which is how it surfaced. Dispose now clears the pool. - EF's SQLite provider puts the database in WAL mode, so the cache is three files. A comment in ClientCacheFactory claimed the opposite; reading PRAGMA journal_mode off a real launch settled it. WAL is the right mode here — a sync pass writes while the interface reads — so the comment was wrong on the merits as well as on the fact. - Enrolling a device key with nowhere to keep the private half would put a wrap on the server nobody can open and make the device list claim this machine can unlock without a passphrase. Device binding is now optional and the shell declines it until the OS keystore is wired. Verified on Windows: the client created %LOCALAPPDATA%\DodoSSH\cache.db and migrated it on first launch, and msedgewebview2 held an established connection to the data plane while the unlock overlay covered it — which is the point of covering the WebView rather than collapsing it, since a NativeWebView that is never laid out is never realised. 630 tests, up from 593. The recovery-code gate and the offline unlock were each verified by breaking them and watching the right test fail. Still to do for M1's actual definition of done: the manual run against the real API and a real Keycloak. Credentials are not a synced entity type yet, so a connection still asks for a password, and the interface says so rather than implying otherwise.	2026-07-29 11:02:19 +02:00