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>

src/DodoSSH.Client.Android/Platform/RendererFocus.cs

@@ -0,0 +1,155 @@
+using global::Android.Views;
+
+namespace DodoSSH.Client.Android.Platform;
+
+/// <summary>
+/// Takes the keyboard away from the terminal's <c>WebView</c>, and reports the taps that should bring it
+/// back.
+/// </summary>
+/// <remarks>
+/// <para>
+/// <b>This replaces <c>TerminalFocus</c>, and it is the opposite move.</b> That class handed Android's own
+/// view focus <em>back</em> to the <c>WebView</c> after Avalonia's <c>DispatchTouchEvent</c> took it, because
+/// the input connection the keyboard was attached to belonged to the page. Under ADR 0015 it no longer does:
+/// <see cref="Views.TerminalInputSurface"/> is the input target, and it is an Avalonia control, so the focus
+/// the platform requests for Avalonia's view after every handled touch is now the focus we want. The fight
+/// ends by removing one of the contestants rather than by refereeing it faster.
+/// </para>
+/// <para>
+/// <b>Non-focusable, not non-interactive, and the distinction is the whole design.</b> Focusability governs
+/// where keyboard and D-pad input go; it has nothing to do with touch delivery. A <c>WebView</c> with
+/// <c>Focusable=false</c> still receives, scrolls and hit-tests every touch it is given — so the page keeps
+/// its <c>touch-action: pan-y</c> scrollback exactly as before — but it can no longer take an input
+/// connection, and Chromium's own <c>showSoftInput</c> for the focused DOM node cannot succeed from an
+/// unfocused view. That is precisely the split wanted: the page keeps the finger, Avalonia keeps the
+/// keyboard.
+/// </para>
+/// <para>
+/// <b>Why a tap has to be reported at all.</b> With the page unable to raise a keyboard, the ordinary way
+/// back after the system back gesture lowers one — touch the terminal — would otherwise do nothing. The
+/// listener is attached with <c>Handled = false</c> throughout, so it observes without consuming: the
+/// <c>WebView</c>'s own <c>OnTouchEvent</c> runs after it exactly as if nothing were listening.
+/// </para>
+/// <para>
+/// A tap is distinguished from a scroll the way every Android view does it, by
+/// <c>ViewConfiguration.ScaledTouchSlop</c>. Without that test, dragging the scrollback would raise the
+/// keyboard over the very output being scrolled to.
+/// </para>
+/// <para>
+/// Found by walking the decor view rather than asked of the <c>NativeWebView</c> control, for the reason
+/// <c>TerminalFocus</c> gave and which has not changed: the control does not expose its platform child, and
+/// this application only ever has the one <c>WebView</c>, so the walk's first match is necessarily the
+/// terminal. Every step is allowed to be absent — there is no activity while backgrounded, and no
+/// <c>WebView</c> until the terminal surface has been shown once.
+/// </para>
+/// </remarks>
+internal static class RendererFocus
+{
+    /// <summary>The view already configured, so that showing the terminal twice does not listen twice.</summary>
+    /// <remarks>
+    /// Weak, because this is a static holding an Android view: a strong reference would keep the whole view
+    /// hierarchy, and the activity behind it, alive for the life of the process.
+    /// </remarks>
+    private static WeakReference<global::Android.Webkit.WebView>? configured;
+
+    /// <summary>
+    /// Makes the renderer unable to hold the keyboard, and calls <paramref name="onTapped"/> when somebody
+    /// taps it.
+    /// </summary>
+    /// <remarks>
+    /// Idempotent, and called on every transition into the terminal rather than once at startup, because the
+    /// <c>WebView</c> does not exist until the surface it lives on has been shown — and because Android is
+    /// free to tear its renderer down and build a new one, which is a case this head already handles
+    /// elsewhere (see <c>docs/android-port.md</c>).
+    /// </remarks>
+    public static void Suppress(Action onTapped)
+    {
+        if (PhoneEnvironment.CurrentActivity?.Window?.DecorView is not ViewGroup decor)
+        {
+            return;
+        }
+
+        if (FindWebView(decor) is not { } webView)
+        {
+            return;
+        }
+
+        if (configured is not null && configured.TryGetTarget(out var already) && ReferenceEquals(already, webView))
+        {
+            return;
+        }
+
+        webView.Focusable = false;
+        webView.FocusableInTouchMode = false;
+        webView.ClearFocus();
+
+        WatchForTaps(webView, onTapped);
+
+        configured = new WeakReference<global::Android.Webkit.WebView>(webView);
+    }
+
+    /// <summary>
+    /// Calls <paramref name="onTapped"/> for a tap, and stays out of the way of everything else.
+    /// </summary>
+    /// <remarks>
+    /// A tap is a press and a release that did not travel further than the platform's own
+    /// <c>ScaledTouchSlop</c> — the same test every Android view uses, and necessary rather than fastidious:
+    /// without it, dragging the scrollback would raise the keyboard over the output being scrolled to.
+    /// </remarks>
+    private static void WatchForTaps(global::Android.Webkit.WebView webView, Action onTapped)
+    {
+        // The fallback is the platform's own historical default, for a context that has somehow gone.
+        var slop = webView.Context is { } context ? ViewConfiguration.Get(context)?.ScaledTouchSlop ?? 8 : 8;
+        var downX = 0f;
+        var downY = 0f;
+        var moved = false;
+
+        webView.Touch += (_, e) =>
+        {
+            // Observed, never consumed. The WebView's own OnTouchEvent still runs, so the page scrolls.
+            e.Handled = false;
+
+            if (e.Event is not { } motion)
+            {
+                return;
+            }
+
+            switch (motion.Action)
+            {
+                case MotionEventActions.Down:
+                    downX = motion.GetX();
+                    downY = motion.GetY();
+                    moved = false;
+
+                    break;
+
+                case MotionEventActions.Move:
+                    moved |= Math.Abs(motion.GetX() - downX) > slop || Math.Abs(motion.GetY() - downY) > slop;
+
+                    break;
+
+                case MotionEventActions.Up when !moved:
+                    onTapped();
+
+                    break;
+            }
+        };
+    }
+
+    private static global::Android.Webkit.WebView? FindWebView(ViewGroup parent)
+    {
+        for (var i = 0; i < parent.ChildCount; i++)
+        {
+            switch (parent.GetChildAt(i))
+            {
+                case global::Android.Webkit.WebView webView:
+                    return webView;
+
+                case ViewGroup child when FindWebView(child) is { } found:
+                    return found;
+            }
+        }
+
+        return null;
+    }
+}

src/DodoSSH.Client.Android/Platform/TerminalFocus.cs

@@ -1,79 +0,0 @@
-using global::Android.Views;
-
-namespace DodoSSH.Client.Android.Platform;
-
-/// <summary>
-/// Hands native focus back to the terminal's WebView after Avalonia chrome took it.
-/// </summary>
-/// <remarks>
-/// <para>
-/// <b>The sibling of <see cref="SoftKeyboard"/>, and it exists for the same reason that one does:</b> the
-/// keyboard over a terminal belongs to the WebView's own native view, which Avalonia's focus manager does
-/// not own. The accessory row's keys are already <c>Focusable=false</c> — see TerminalScreen — so Avalonia's
-/// idea of focus never leaves the terminal when one is tapped. What still moves is <em>Android's</em>:
-/// <c>AvaloniaView.DispatchTouchEvent</c> (decompiled from Avalonia.Android 12.1.1) ends every handled
-/// touch — DOWN and UP alike — with a <c>RequestFocus()</c> for Avalonia's own view. The WebView's input
-/// connection dies with its focus, the keyboard swaps to the layout it shows an editor that takes no text,
-/// and the inset churn that follows can leave it sitting on top of the very row that was tapped.
-/// </para>
-/// <para>
-/// <b>Posted, not called — the posting is the fix's second attempt, and the first one's failure is why.</b>
-/// The first version called <c>RequestFocus()</c> from the keys' own Click handlers, which fire
-/// <em>inside</em> the UP event's dispatch — and the platform's own request runs <em>after</em> dispatch
-/// returns, so it undid ours a few microseconds later and the terminal stayed unfocused. A posted runnable
-/// runs on the next main-looper message, after the platform has taken its turn, so ours is the request that
-/// sticks. The focus check lives inside the posted runnable for the same reason: the answer at call time is
-/// about to be made stale by the very mechanism this exists to counter.
-/// </para>
-/// <para>
-/// The page inside the WebView never noticed any of this — its own DOM focus never moved — so regaining
-/// native focus re-establishes the same input connection and the keyboard settles back to what it was.
-/// </para>
-/// <para>
-/// Found by walking the decor view rather than asked of the <c>NativeWebView</c> control, because the
-/// control does not expose its platform child and this application only ever has the one WebView — the
-/// walk's first match is necessarily the terminal. Every step is allowed to be absent, exactly as
-/// <see cref="SoftKeyboard.Hide"/>'s are: no activity while backgrounded, no WebView while the terminal
-/// surface has never been shown, and nothing to do in either case.
-/// </para>
-/// </remarks>
-internal static class TerminalFocus
-{
-    public static void Return()
-    {
-        if (PhoneEnvironment.CurrentActivity?.Window?.DecorView is not ViewGroup decor)
-        {
-            return;
-        }
-
-        if (FindWebView(decor) is not { } webView)
-        {
-            return;
-        }
-
-        webView.Post(() =>
-        {
-            if (!webView.IsFocused)
-            {
-                webView.RequestFocus();
-            }
-        });
-    }
-
-    private static View? FindWebView(ViewGroup parent)
-    {
-        for (var i = 0; i < parent.ChildCount; i++)
-        {
-            switch (parent.GetChildAt(i))
-            {
-                case global::Android.Webkit.WebView webView:
-                    return webView;
-
-                case ViewGroup child when FindWebView(child) is { } found:
-                    return found;
-            }
-        }
-
-        return null;
-    }
-}