2 Commits

Include renames

Author	SHA1	Message	Date
jaap-jan	d459dac600	Stop a dead WebView2 hanging Connect with the busy flag stuck ... VaultViewModel.ConnectAsync awaited TerminalWorkspace.WaitForRendererAsync with no timeout and no token, and RunAsync clears IsBusy only after the work returns. Whether the renderer attaches at all depends on a runtime this application does not install: with a missing or policy-blocked Evergreen runtime, or an AppContainer that cannot reach loopback, the socket never arrives — so Connect never returned, the window stayed disabled on "Connecting…" for the rest of the session, and nothing on screen said why. Left out of 0500e43 to keep that change focused, and recorded in docs/platform-flags.md as worth fixing on its own merits. The gate itself is unchanged and has to stay: TerminalDataPlane.SendAsync drops frames when no renderer is attached rather than queueing them, so a session opened before the renderer arrives loses its SessionOpened frame and then streams output at a terminal that was never created. Only the wait changed — RendererAttached.WaitAsync(timeout, cancellationToken), with the command's own token threaded through. Fifteen seconds, on TerminalWorkspaceOptions.RendererTimeout. Attaching is normally near-instant, since WebView2 starts with the window and the page has usually attached while the passphrase was still being typed, but a first run on a cold profile creates a user-data directory and starts a process tree of some thirty-five processes first, which on a loaded machine is seconds rather than milliseconds. A renderer that will never attach will not attach however long the wait is, so being generous costs only how long a broken runtime takes to say so, while being tight costs telling someone their runtime is broken when it was merely slow. Injectable because both new tests would otherwise sit out that budget. The timeout is caught in VaultViewModel rather than left to RunAsync's generic handler, because TimeoutException.Message is "The operation has timed out" — which sends someone looking at their network or their host. The status now names the WebView2 runtime and says to install it. TerminalWorkspaceTests covers the half that was missing: the wait gives up (329 ms against a 250 ms budget) and obeys its token (2 ms against a five-minute one). Before the bound, the first of those would have hung rather than failed. ShellFlowTests never starts its workspace, which from the view model's side is indistinguishable from a WebView2 that failed to initialise, so it asserts that the status names WebView2 and that IsBusy is cleared; changing the catch to another exception type makes it fail with "The operation has timed out.", so neither assertion is vacuous. The success path is untouched and still covered end to end by TerminalEndToEndTests against a real sshd container, which now passes the test's cancellation token. One byproduct: the doc comment on WaitForRendererAsync carried two double-encoded em dashes, fixed now that the block is rewritten.	2026-07-29 15:26:53 +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