Files
DodoSSH/src/DodoSSH.Client.App/Views/ConnectingCard.axaml
T
jaap-jan e2733e5cbc
ci / build and test (push) Successful in 3m28s
ci / android head (push) Successful in 4m48s
ci / desktop nightly (push) Successful in 1m17s
ci / api image (push) Successful in 28s
Notice when a shell ends, say which way it ended, and offer the way back
A terminal whose machine rebooted stayed green for ever. Not "went stale and
recovered late" — for ever: the tab claimed CONNECTED, the elapsed timer went
on counting, and the only thing that ever corrected it was closing the
application. That is the defect this fixes, and it turned out to be two
separate failures wearing one symptom.

◆ THE HANG IS IN SSH.NET, AND KEEP-ALIVE ALONE WOULD NOT HAVE FIXED IT.

ShellStream ends a blocked read from exactly two places: its channel being
closed, and the session raising Disconnected. A shell that exits gives the
first. But Session raises Disconnected from one method only — OnDisconnectReceived,
for a server that politely says goodbye — and a socket that simply fails goes
down a different path entirely: RaiseError fires the error event, sets the
disconnecting flag and disposes the socket, without ever raising Disconnected.
So the stream was never disposed, its Monitor.Wait was never pulsed, and the
read blocked until the process ended. The transport was gone, the client knew
the transport was gone, and nothing woke the one thread that was waiting.

That is why the first attempt at a test for this sat at thirty seconds and
failed. Both halves are needed and neither is sufficient:

  - Keep-alive makes the failure HAPPEN. An idle SSH session is a socket
    nobody writes to, and TCP has no way to discover that the far end has gone
    without writing to it — nothing was asked, so nothing could fail. Thirty
    seconds, matching OpenSSH's own ServerAliveInterval examples. It is the
    write that matters and not a reply: SSH_MSG_IGNORE need not be answered,
    so this is traffic rather than a heartbeat with a deadline, and there is
    no timeout invented here to be wrong about a slow link.

  - Disposing the stream from the error handler makes it ARRIVE. Queued to the
    thread pool and not done inline, which is not tidiness: this runs on
    SSH.NET's message-listener thread, and closing a channel waits for the
    server's close — processed by that same thread — so an inline dispose is
    the listener thread waiting on itself.

SFTP gets the keep-alive too. Its operations are request/response and bounded
by ConnectionInfo.Timeout already, so it needs no equivalent wake-up.

◆ exit AND reboot ARE TOLD APART BY A LATCH, BECAUSE THE OBVIOUS WAY IS A RACE.

Wait for the read to end and then ask whether the transport is still up, and
against a real server the answer is wrong about half the time: this was the
only channel on the connection, so sshd hangs up a millisecond after closing
it. By the time anything could ask, the transport is gone either way — and a
poll would report every ordinary `exit` as a dropped connection.

So ISshShellSession.TransportFailure is set at the moment SSH.NET raises the
failure, which its own ordering puts strictly before the disconnect that wakes
the read. A read that has just returned zero consults a settled value: set if
the transport failed, still null if the remote merely closed the channel. The
pump turns that into a TerminalSessionOutcome — RemoteClosed, ConnectionLost,
ClosedLocally — carried on SessionEnded, which used to hand over a session id
and nothing else. A subscriber cannot work this out afterwards; by the time it
hears, there is no transport left to interrogate.

Deliberately no fourth value for "the remote rebooted". Nothing on the wire
distinguishes a reboot from a cable being pulled, and a name this client
cannot check would be a guess dressed as a fact.

◆ WHAT IS DRAWN, AND WHY IT IS NOT DRAWN OVER THE PANE.

The status bar says DISCONNECTED or SHELL EXITED where it used to say NOT
CONNECTED for both — a word that is honest about a tab still dialling and
useless about one whose shell has stopped. Red for the first and grey for the
second: one is a machine that stopped answering and the other is work
finished, and crying wolf on the ordinary end of every session is its own bug.
The tab strip's dot gains the same fourth state, on both heads.

Under the terminal, a strip carrying the reason and two buttons. It takes its
own Auto grid row rather than overlaying the renderer, and that is forced
rather than chosen: the WebView is a native child view composited above
everything Avalonia draws, so the alternative is collapsing the terminal — and
the scrollback is precisely what the user wants to read, because the last
thing the remote said is usually why it went. terminal.js already writes the
same sentence into the pane; this is the copy that does not scroll away.

RECONNECT reuses the tab in place, which is what the word means to somebody
who pressed it: the terminal they were working in comes back, where it was.
It dials through the vault's ordinary connect path, so every refusal — a key
that has left the keychain, an unknown host key, a group default that has
changed since — is decided in the one place that already decides them; what
this adds is which tab the attempt belongs to. The old session is closed as
part of it, because a dead shell still holds an authenticated connection this
process has stopped reading, and its pane still holds an xterm, a scrollback
and a WebGL context, of which a browser hands out about sixteen.

Two refusals it makes rather than pretending: a host reached by typing an
address has no keychain entry to redial, and one that wants a password typed
goes to the keychain with the sheet raised rather than being dialled with an
empty box. Both say so on the strip where the button was pressed, not only in
the vault's status on a screen that surface is not.

TRY AGAIN appears on a refused connection for the same reason, and it is worth
as much: the commonest refusal is a host that was not up yet.

◆ WHAT IS ACTUALLY VERIFIED.

Two tests against a real sshd in a container. `exit` is reported as the remote
closing the session — the one a polling implementation fails, and a fake shell
cannot show it because a fake has no server behind it deciding to hang up. And
a live shell losing its transport is reported as a lost connection, produced
by dialling through a plain TCP relay the test owns and then cutting it; the
container is shared by the collection, so killing sshd was never an option.

The first draft of that second test used LoopbackProxyTests' SOCKS forward and
timed out: disconnecting the carrier of a ForwardedPortDynamic does not close
the loopback socket it accepted. Recorded in the test, because it is a
property of SSH.NET's forwarder rather than of anything here, and it is not
what a dying machine looks like.

What no test reproduces is the waiting. A relay that closes sends a FIN, so
the socket reports itself at once; a machine switched off sends nothing, and
finding that out is the keep-alive's business and the OS's retransmit budget's
— neither of which a test can hurry along without a clock this code does not
own. A reboot is prompt in practice because the machine comes back and RSTs.

Beside those: three pump outcomes, three workspace announcements, and seven
shell-flow tests covering the drop, the clean exit, reuse of the tab, retry
after a refusal, and both ways a reconnect can honestly come to nothing.

Also fixed in passing: SshNetShellSession.IsOpen read ShellStream.CanRead,
which is documented as always true — the stream stays readable after disposal
so buffered output can be drained — so it had answered "yes" for every shell
that ever existed. It reads CanWrite now. And MainWindowViewModel's session-
ended handler moved from Dispatcher.UIThread.Post to the injected post
delegate, which is what makes any of the shell half testable at all; the
remark listing the three unreachable posts is one shorter.
2026-08-24 10:36:15 +02:00

211 lines
12 KiB
XML

<UserControl xmlns="https://github.com/avaloniaui"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
xmlns:vm="using:DodoSSH.Client.Shell.ViewModels"
x:Class="DodoSSH.Client.App.Views.ConnectingCard"
x:DataType="vm:MainWindowViewModel"
Background="{StaticResource Canvas}">
<!--
What the terminal's rectangle holds while the selected tab has no pane: a connection being made, or one
that was refused.
It exists because connecting stopped blocking the window. The tab appears the moment the user asks for
it and the handshake runs behind it, so there is a stretch — seconds against a machine that is asleep,
longer against one that is not there — in which a tab is selected and there is nothing to show in it.
Showing the last terminal's pane would be a lie, and showing nothing reads as the application having
broken, so this says which machine, as whom, and how far along it is.
── The step list, and why it is amber ───────────────────────────────────────────────────────────────
"How far along it is" used to be one line of prose that never changed after the tab was created, which
made every slow connection look exactly like every hung one. It is now the five steps of actually
getting there, each lit at the moment the handshake reports it — see SshConnectionPhase, which names
only the boundaries a client can genuinely observe. A connection that stops therefore stops on a named
row, and "the host key is being checked" stops being the same screen as "the host is not answering".
Amber for the step in flight, and that is the palette's rule rather than an exception to it. Green is
what is true and purple is what you can press; a step still happening is neither, and it is precisely
the caveat-worth-reading amber exists for — see the remark above Warn in Palette.axaml. Steps behind it
go green as they become true, and the one a refusal landed on goes red. Nothing on the list is drawn in
the accent, because there is nothing on it to press.
Nothing here animates, which is the argument the transfer strip makes for its own track in
TransfersScreen.axaml, arriving at a screen with more reason to want a spinner. A spinner is furniture
invented to fill a state nobody measured; these steps are measured, so the track fills to what has
actually finished and then waits there. Waiting is what waiting looks like.
The list is drawn for both states rather than once per state. A refused connection has the same five
rows and the same track — the difference is only that one row is red and the track stops — and drawing
it twice would be two templates to keep identical for the sake of a colour.
It obeys the occlusion rule the whole window obeys: this is Avalonia-drawn content in the WebView's own
rectangle, so the shell collapses the terminal while it is up. IsTerminalShowing and IsConnectingShowing
are exclusive by construction — a selected tab either has a session or it does not — which is what makes
that safe rather than merely arranged. See MainWindow.axaml.
In its own file rather than in the window, like every other card here, because nothing inside that window
can be laid out by a test: WebView2's adapter refuses the headless session's thread.
-->
<UserControl.Styles>
<!--
A rule per lit state over one quiet default, so that the pending weight is stated once and each state
that differs from it is the one line that says how.
-->
<Style Selector="TextBlock.stepcaption">
<Setter Property="Foreground" Value="{StaticResource TextFaint}" />
<Setter Property="FontSize" Value="12" />
<Setter Property="VerticalAlignment" Value="Center" />
</Style>
<Style Selector="TextBlock.stepcaption.done">
<Setter Property="Foreground" Value="{StaticResource TextDim}" />
</Style>
<Style Selector="TextBlock.stepcaption.running">
<Setter Property="Foreground" Value="{StaticResource WarnText}" />
<Setter Property="FontWeight" Value="Medium" />
</Style>
<Style Selector="TextBlock.stepcaption.stopped">
<Setter Property="Foreground" Value="{StaticResource DangerText}" />
</Style>
<!--
The marker beside each caption. Fixed width and centred, because four different characters on a
ragged left edge is a list that looks broken; see ConnectionStepViewModel.Mark for which they are.
-->
<Style Selector="TextBlock.stepmark">
<Setter Property="Foreground" Value="{StaticResource BorderMid}" />
<Setter Property="FontSize" Value="12" />
<Setter Property="Width" Value="14" />
<Setter Property="TextAlignment" Value="Center" />
<Setter Property="VerticalAlignment" Value="Center" />
</Style>
<Style Selector="TextBlock.stepmark.done">
<Setter Property="Foreground" Value="{StaticResource Live}" />
</Style>
<Style Selector="TextBlock.stepmark.running">
<Setter Property="Foreground" Value="{StaticResource Warn}" />
</Style>
<Style Selector="TextBlock.stepmark.stopped">
<Setter Property="Foreground" Value="{StaticResource Danger}" />
</Style>
<!--
The track over the list. Amber while the attempt is alive and red once it is not, so that the bar says
the same thing as the row it stopped on rather than staying the colour of something still being waited
for. Chip underneath, matching the transfer strip's track.
-->
<Style Selector="ProgressBar.steptrack">
<Setter Property="Height" Value="5" />
<Setter Property="MinHeight" Value="5" />
<Setter Property="CornerRadius" Value="3" />
<Setter Property="Background" Value="{StaticResource Chip}" />
<Setter Property="Foreground" Value="{StaticResource Warn}" />
</Style>
<Style Selector="ProgressBar.steptrack.stopped">
<Setter Property="Foreground" Value="{StaticResource Danger}" />
</Style>
</UserControl.Styles>
<Panel>
<StackPanel VerticalAlignment="Center" HorizontalAlignment="Center" Spacing="18" MaxWidth="460"
Margin="24">
<StackPanel Spacing="6" HorizontalAlignment="Center">
<TextBlock Classes="mono" Text="{Binding SelectedTab.Label}" FontSize="16" FontWeight="Medium"
Foreground="{StaticResource Text}" HorizontalAlignment="Center"
TextTrimming="CharacterEllipsis" />
<TextBlock Classes="mono" Text="{Binding SelectedTab.Address}" FontSize="11.5"
Foreground="{StaticResource TextFaint}" HorizontalAlignment="Center"
TextTrimming="CharacterEllipsis" />
</StackPanel>
<!--
Bound to StepsDone against StepCount rather than to a percentage: five steps and a maximum of five
means the bar is a count of things that really finished, and the arithmetic that would turn it into
a percentage is exactly the arithmetic that would start inventing one.
-->
<ProgressBar Classes="steptrack" Classes.stopped="{Binding SelectedTab.IsFailed}"
Minimum="0" Maximum="{Binding SelectedTab.StepCount}"
Value="{Binding SelectedTab.StepsDone, Mode=OneWay}" />
<ItemsControl ItemsSource="{Binding SelectedTab.Steps}" HorizontalAlignment="Center">
<ItemsControl.ItemsPanel>
<ItemsPanelTemplate>
<StackPanel Spacing="7" />
</ItemsPanelTemplate>
</ItemsControl.ItemsPanel>
<ItemsControl.ItemTemplate>
<DataTemplate x:DataType="vm:ConnectionStepViewModel">
<StackPanel Orientation="Horizontal" Spacing="10">
<TextBlock Classes="stepmark"
Classes.done="{Binding IsDone}"
Classes.running="{Binding IsRunning}"
Classes.stopped="{Binding IsStopped}"
Text="{Binding Mark}" />
<TextBlock Classes="stepcaption mono"
Classes.done="{Binding IsDone}"
Classes.running="{Binding IsRunning}"
Classes.stopped="{Binding IsStopped}"
Text="{Binding Caption}" />
</StackPanel>
</DataTemplate>
</ItemsControl.ItemTemplate>
</ItemsControl>
<!--
A refusal is the reason, in the palette's red, because it is the only place the reason will be after
the user navigates away from the screen that started the connection. It sits under the list rather
than replacing it: which row it stopped on is half the answer and the sentence is the other half.
-->
<SelectableTextBlock Text="{Binding SelectedTab.Status}" FontSize="13"
Foreground="{StaticResource Danger}" HorizontalAlignment="Center"
TextWrapping="Wrap" TextAlignment="Center"
IsVisible="{Binding SelectedTab.IsFailed}" />
<TextBlock Classes="hint" FontSize="11.5" TextAlignment="Center" HorizontalAlignment="Center"
Text="Nothing else is waiting for this. Every other screen still works, and the strip above says how this one is getting on."
IsVisible="{Binding SelectedTab.IsConnecting}" />
<!--
The same command the tab's own cross runs, named for what pressing it means in each of the two
states. On a connecting tab it is how the attempt is given up on: the shell forgets it, and a
handshake that finishes afterwards is adopted rather than dropped — see
MainWindowViewModel.CloseTabAsync. Two buttons rather than one with a converted label, because the
two are different decisions and only one of them abandons something still running.
Beside each, the logs. The step list is this attempt and the log is every other one, which is the
question both a connection taking too long and a connection just refused actually raise — has this
machine ever worked. It is the ordinary rail destination reached the ordinary way rather than a
second log grown inside this card, and leaving by it does not abandon the handshake: the tab stays
in the strip and the card is still here on the way back.
-->
<StackPanel Orientation="Horizontal" Spacing="10" HorizontalAlignment="Center">
<!--
TRY AGAIN rather than RECONNECT, because nothing was ever connected: this tab is a handshake that
was refused. It runs the same command the disconnect strip's RECONNECT does — the vault's own
connect path, into this same tab — and it is worth having here for the reason the commonest
refusal is worth retrying at all: a host that was not up yet is a host that will be in a minute.
Disabled rather than hidden when there is nothing to dial, exactly as the strip's is. See
MainWindowViewModel.CanReconnectSelectedTab.
-->
<Button Classes="ghost" Content="TRY AGAIN" Command="{Binding ReconnectTabCommand}"
CommandParameter="{Binding SelectedTab}"
IsEnabled="{Binding CanReconnectSelectedTab, FallbackValue=False}"
IsVisible="{Binding SelectedTab.IsFailed}" />
<Button Classes="ghost" Content="SHOW LOGS" Command="{Binding ShowScreenCommand}"
CommandParameter="{x:Static vm:ShellScreen.Logs}" />
<Button Classes="ghost" Content="GIVE UP" Command="{Binding CloseTabCommand}"
CommandParameter="{Binding SelectedTab}"
IsVisible="{Binding SelectedTab.IsConnecting}" />
<Button Classes="ghost" Content="CLOSE TAB" Command="{Binding CloseTabCommand}"
CommandParameter="{Binding SelectedTab}"
IsVisible="{Binding SelectedTab.IsFailed}" />
</StackPanel>
</StackPanel>
</Panel>
</UserControl>