Public Access
jaap-jan
9bc9069425
The first fix handed Android's focus back from inside the keys' Click handlers — which fire inside the UP event's dispatch, and Avalonia's own view requests focus for itself after every handled touch dispatch returns (AvaloniaView.DispatchTouchEvent, decompiled from 12.1.1). So the platform's request ran after ours and undid it microseconds later, which is exactly what the phone showed: the terminal still lost focus. The return is now posted onto the main looper, landing one message after the dispatch that stole, and it is wired at the row for both halves of a press — DOWN steals too, and Click only exists for UP, so a keyboard detached at DOWN would otherwise stay detached for the whole length of the press. Check 11.10a now also says what a tolerable blink looks like against a failure that stays.
80 lines
3.4 KiB
C#
80 lines
3.4 KiB
C#
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;
|
|
}
|
|
}
|