3 Commits

Include renames

Author	SHA1	Message	Date
laurensandClaude Opus 5	1908189100	Make the terminal's right button copy and paste, and never open a menu ... Selecting output and right-clicking it opened the WebView's own context menu with Copy on it, which is correct behaviour for a web page and wrong for a terminal. What a terminal's right button has meant since the Windows console got QuickEdit, and since PuTTY shipped, is this: with something selected it copies and drops the selection, with nothing selected it pastes. No menu, no second click. The gesture can only live in the page. The selection is drawn into a canvas the host never sees, and once a terminal has focus the host's window receives no input events at all — the same reason the Ctrl+plus chords are handled there. ◆ THE CLIPBOARD IS THE HOST'S IN BOTH DIRECTIONS, AND THE READING IS WHY. navigator.clipboard.readText() is gated behind the clipboard-read permission in every Chromium, and an embedded WebView with no PermissionRequested handler answers a permission request by putting a prompt on the screen. Trading a context menu for a permission dialog is not this change. So the page asks and the host answers, exactly as requestFontSizeStep does. Writing does not go the other way either, although navigator.clipboard.writeText would have worked from the page on Windows: a clipboard that is the host's in one direction and the page's in the other is two mechanisms to keep working across WebView2, WebKitGTK and Android's WebView. The host has owned a clipboard delegate since the keychain grew its COPY buttons, so each App.axaml.cs grows a ClipboardReader beside its ClipboardWriter and MainWindowViewModel takes it. Three opcodes: client ClipboardCopy and ClipboardPaste, server Clipboard. ◆ Clipboard IS NOT Paste, AND THE DIFFERENCE IS THE BRACKETING. Paste carries a snippet off the sidebar, and the page deliberately *types* a single-line one rather than bracketing it, because bash marks a bracketed paste as an active region and a snippet should read as though it had been typed. A clipboard paste is the case those markers are for — readline uses them to decide it has been pasted into — so Clipboard is always bracketed and never followed by an Enter. One opcode for both would have needed a flag meaning "which of the two kinds of paste is this", on a payload whose existing flag byte means something else. Both client frames are dispatched before the session lookup, which is what keeps the gesture working in a pane whose shell has just ended: squinting at the message a remote left behind is exactly when somebody copies the line. Dispatch was past MA0051's length once it grew a second such branch, so the frames no pump needs to see moved into Announce() and the font-size chord went with them. ◆ CAPTURED AND STOPPED, RATHER THAN MERELY PREVENTED. preventDefault alone suppresses the menu and still lets xterm's own contextmenu handler run, which moves its helper textarea under the pointer at z-index 1000 and leaves the selection sitting in it, selected. Both of those exist to serve the native menu. Taking the event in the capture phase on the pane and stopping it there is what keeps the gesture wholly the page's. rightClickSelectsWord is now false, which on macOS is a change of default rather than a restatement of it: xterm sets it true there alone, so a right-click would have selected the word under the pointer and copied that instead of pasting — wrong on one platform only, which is the worst way for it to be wrong. The renderer harness grows the pane it has been inviting since RendererReconnectionTests: a fake Terminal, the two addons, and a real UTF-8 codec, because both directions run through the page's own TextEncoder and TextDecoder and a Latin-1 stub would pass a test with an em dash in the selection. Its warning about declaring names terminal.js declares now covers the half that does not SyntaxError — a harness frame() was silently replaced by the page's frame() and failed six tests on a type error a long way from the cause. Manual checks 1.11 and 11.13 are what is left for a person: that a real contextmenu event reaches a capture listener, that no native menu is drawn once it is prevented, and that xterm's real paste() brackets. 11.13 also records what is unverified — whether Android's WebView delivers a pointer's secondary click as a contextmenu event at all. ClipboardReader is wired on that head regardless, because the alternative is a head where the paste half silently does nothing and nobody finds out; that head is not compiled here either, this machine having no android workload. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-25 14:46:36 +02:00
jaap-jan	74341d41e0	Merge branch 'claude/distracted-ritchie-53fc70' ... Bounds the renderer wait, so a WebView2 that never initialises reports itself instead of hanging Connect with the busy flag stuck. Conflict resolution, all of it in the App test suite, which main had changed under the branch when sleepy-chebyshev landed: - The workspace fixture keeps main's fake SSH factory and its FakeRenderer-aware page, and takes the branch's RendererTimeout on top. One second rather than the branch's 250 ms, because the timeout now also bounds FakeRenderer's own wait for the attach it just made. - FakeRenderer arrived on main after the branch was cut and still called the no-argument WaitForRendererAsync. Both sides merged cleanly and left the build broken; it now passes its own token. - ConnectingWithNoRenderer's remark claimed the suite never starts the workspace and never attaches a renderer. Both are false here, so it now says what is true of the test: it is the one connect test that attaches no renderer.	2026-07-29 15:40:25 +02:00
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