2 Commits

Include renames

Author	SHA1	Message	Date
jaap-janandClaude Opus 5	2810f7c12b	Stop the terminal's Enter key dismissing the keyboard it was typed on ... The first device run of ADR 0015 found the premise held and the field misconfigured in a second way: the suggestion strip, autocorrect and predictive text were all gone, and every Enter closed the keyboard. On a terminal that is every command, so the phone asked for a tap between each one. TerminalInputSurface had been left with Avalonia's default ReturnKeyType, and the same OnCreateInputConnection that carries the inputType fix maps that default, on a field that is not Multiline, to IME_ACTION_DONE: _ => options.Multiline ? 1073741824 : 6, // 6 is IME_ACTION_DONE Done means done. The keyboard performs the action and dismisses itself, which is right for the text box the default was written for and wrong for a surface where Enter is punctuation rather than submission. TextInputReturnKeyType.Return is the member that maps to IME_ACTION_NONE — value 1, so `returnKeyType - 1 => 0 => 1073741824` — leaving Enter a plain newline with no action attached and no reason for the IME to hide. ◆ THE TRAP, WHICH IS THE ONE 11.10b ALREADY WARNED ABOUT FROM THE OTHER SIDE. Multiline=true also reaches IME_ACTION_NONE, through that same default arm, and is the obvious fix and the wrong one. It ORs TYPE_TEXT_FLAG_MULTI_LINE into InputType, which moves it off 1 and silently fails the ShowSuggestions guard the whole ADR turns on. Taking the obvious route to a working Enter would have handed the suggestion strip back and looked like the premise had failed rather than like the fix had. ReturnKeyType touches imeOptions only, which is why it is what is set. Enter's byte was never the problem and is not what changed: IME_ACTION_DONE was already synthesising KEYCODE_ENTER through AvaloniaInputConnection.PerformEditorAction, so commands did run — the keyboard just left afterwards. OnTextInput now also normalises line endings to CR. Belt and braces for the case this change makes newly possible: a keyboard with no editor action attached may commit "\n" as ordinary text rather than sending KEYCODE_ENTER, and a shell handed LF for Enter looks like a shell that ignored the key. Normalising rather than special-casing also stops a pasted "\r\n" running its line twice. Check 11.10e is the regression test, and says in as many words not to fix a recurrence with Multiline. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-25 10:29:38 +02:00
jaap-janandClaude Opus 5	c0dd5a147e	Give the phone's terminal its own keyboard, and stop refereeing a focus fight ... Typing into a shell on the phone has been the worst thing about this head, and the reason is not the renderer. It is that the keyboard over the terminal was configured by Chromium rather than by us: a prose keyboard, with a suggestion strip, autocorrect, autocapitalisation and a predictive layer that inserts text ahead of the cursor — over a surface where every character is a command. The obvious fix does not exist. xterm.js already sets every hint the web platform has on its helper textarea — autocorrect, autocapitalize and spellcheck are all off in the vendored bundle — and Android ignores all three, because they are advisory. What actually silences a keyboard on this platform is an inputType carrying TYPE_TEXT_VARIATION_VISIBLE_PASSWORD, which is what Termux's own TerminalView sets and the reason typing in Termux feels like a terminal. A page inside a WebView cannot reach that field: Chromium derives the whole EditorInfo from the focused DOM node, and no attribute produces the visible-password variation. Avalonia can reach it, on the version already pinned here. Decompiled from Avalonia.Android 12.1.1, AndroidInputMethod.OnCreateInputConnection: if ((int)outAttrs.InputType == 1 && options.ShowSuggestions == false) outAttrs.InputType = (InputTypes)(outAttrs.InputType | 0x80080); 0x80080 is VISIBLE_PASSWORD | NO_SUGGESTIONS — Termux's pair exactly. So the keyboard behaviour wanted is one attached property away from any Avalonia control, and permanently out of reach of the WebView. That asymmetry is the whole decision; ADR 0015 records it, along with the two stages deliberately not taken and what would falsify the premise. ◆ THE INPUT PATH LEAVES THE WEBVIEW. THE RENDERER DOES NOT MOVE. TerminalInputSurface is a 1x1 focusable control that draws nothing and is where every character typed into a shell now arrives. It is not stretched over the renderer, which would be the obvious shape and is wrong three times over: the WebView composites above everything Avalonia paints so it would be invisible, it would never see the touches the WebView consumes first, and it would sit over the connect page sharing that Panel whenever no session is open. Focus does not need area. Its IME client retains nothing and claims nothing — no surrounding text, no preedit — because a terminal has no document for an input method to edit. The line being edited is on the far side of an SSH channel and this client has never been told what is on it. ◆ THE FOCUS FIGHT ENDS BY REMOVING A CONTESTANT. TerminalFocus is deleted rather than amended. It existed to hand Android's own view focus back to the WebView after AvaloniaView.DispatchTouchEvent took it at both ends of every touch, and it was correct for as long as the input connection belonged to the page. It no longer does, so the focus the platform hands to Avalonia's view is now the focus the keyboard wants. The accessory row's two posted counter-moves go with it; the keys stay Focusable=false, which is now what keeps Avalonia's focus on the input surface. RendererFocus replaces it with the opposite move: the WebView is made non-focusable, so it cannot take an input connection and Chromium's own showSoftInput cannot succeed from it. Non-focusable is not non-interactive — focusability governs keyboard input, not touch delivery — so the page keeps its pan-y scrollback untouched. What it can no longer do is raise a keyboard, so taps on it are observed with Handled=false throughout and reported, filtered by the platform's own ScaledTouchSlop. Without that filter, dragging the scrollback would raise the keyboard over the output being scrolled to. ◆ TWO THINGS FOUND ON THE WAY, ONE OF THEM OLD. The Ctrl latch never worked with the software keyboard. Not a regression and not new — everything typed went straight into the page and never passed SendAsync, which is where the latch lives, so `ctrl` then `c` was inert unless the second key also came from the accessory row. Routing input through Avalonia fixes it as a side effect, and check 11.10d exists to keep it fixed. Avalonia raises a text-input event for any key whose UnicodeChar is 32 or above, whether or not the key event was handled — it reads the handled flag only to fold into its own return value. Ctrl-C on a hardware keyboard therefore produced 0x03 and then a literal c. controlByteAlreadySent swallows the second. The keys in TryTranslate need no such guard, their UnicodeChars being below 32. One deliberate loss, in the open: Delete sends backspace. Avalonia turns an IME's deleteSurroundingText into a dispatched KEYCODE_FORWARD_DEL, so a soft keyboard taking that route is indistinguishable here from a real Delete key — and a backspace that deletes forwards on every phone is worse than a missing forward-delete on the few devices that have one. Nothing here is verifiable without a device, so the checks are written rather than the tests: 11.10b is the falsification test and should be run first, because everything staged on this stands or falls on whether one attached property actually silences a real keyboard. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-25 10:12:14 +02:00