2 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	5fccd53824	Add the Avalonia app and the xterm renderer, and fix two real bugs ... The terminal works end to end. A new integration test drives a real sshd in a container through a real PTY, the real pump, the real loopback WebSocket with its token and origin checks, and a ClientWebSocket standing in for the page: the login banner arrives, typed input round-trips, and `stty size` reports the 100x30 the session asked for. The only untested link left is xterm drawing bytes it was handed. The WebView is de-risked on Windows, which was the plan's largest risk. Not by assertion: with the app running there is an established TCP connection from msedgewebview2 to the data plane port, so WebView2 launched, navigated to the loopback page, executed terminal.js, and completed the WebSocket handshake against the real token and origin checks. Linux remains unproven and the package's own release notes now corroborate the concern -- Linux uses a WPE backend, and it ships a NativeWebDialog described as useful where embedded WebViews may be unavailable. Two bugs found by building it, both of which would have shipped: - ShellStream.Write buffers and needs an explicit Flush. Without one a keystroke is accepted, reported as written, and never reaches the remote: the terminal displays output perfectly and simply stops responding to input. SSH.NET's own WriteLine flushes, which is why the earlier spike never hit it. Found by isolating the pump against real SSH and reading BytesRead=51 -- banner and prompt through, nothing after. - The Windows app manifest needs a supportedOS list, or Avalonia's native control host fails outright and the terminal never starts. Also fixed a genuinely flaky test I happened to catch: SyncCursorTests tampered with the *last* base64url character, whose low bits the decoder ignores when the input length is not a multiple of three -- so a tampered cursor sometimes decoded to identical bytes and verified. It failed roughly one run in thirty, depending on a random key. Now tampers the penultimate character, which is fully significant at every length; 40 consecutive runs are clean. xterm 6.0.0 plus the fit and webgl addons are vendored as UMD bundles rather than built with npm, so a clean clone needs only the .NET SDK. Provenance and licences are recorded next to them, along with the UMD global names terminal.js depends on -- a bundle that switched to ES modules would load without error and leave Terminal undefined. The renderer acknowledges output from term.write's completion callback, not on receipt. Acknowledging early would return flow-control credit for bytes the screen has not caught up with, which is the one thing the credit window exists to measure. TerminalWorkspace moved into DodoSSH.Client.Terminal: it has no Avalonia dependency, and having it there is what let the end-to-end test exist at all. 404 tests pass, zero warnings on a clean rebuild, format clean.	2026-07-28 22:30:42 +02:00