Compare commits

...
Author SHA1 Message Date
jaap-jan b2f93a172b Give the file listings' columns their content back
ci / desktop nightly (pull_request) Skipped
ci / android head (pull_request) Successful in 3m7s
ci / build and test (pull_request) Successful in 2m32s
ci / api image (pull_request) Successful in 4s
The columns in both panes were fixed pixel widths, and measuring them against
what they actually draw found them wrong at both ends of the range this screen
gets.

◆ MODIFIED WAS TRUNCATED AT EVERY WIDTH THE APPLICATION HAS EVER BEEN DRAWN AT.
It prints a sixteen-character timestamp, which needs 116 pixels, and it had 52.
On a maximised window that read "2026-08" beside a NAME column with four
hundred empty pixels in it. PERMS needs 60 for a ten-character mode and had 48;
SIZE needs 58 for "999.9 GB" and had 56.

◆ AND AT THE SESSION SHELL'S OWN NARROWEST, NAME MEASURED ZERO PIXELS. Twenty
for the glyph plus 56+52+48 for the numbers is 176 of the 180 a row has, so the
remote pane drew sizes, timestamps and modes for rows whose names were not on
screen at all. That is the same fault as the one above rather than a second
one: the numbers were picked for the narrow budget, could not have fitted their
own content there, and never grew anywhere else.

Star columns with a MaxWidth answer both, because the cap is what makes "share
the width" mean the right thing at each end. Wide, the three numeric columns
stop growing at what their text needs and NAME keeps every remaining pixel.
Narrow, nothing carries a MinWidth to overflow with, so all four give ground
together and NAME — weighted heaviest — is the last to run out. MODIFIED takes
the extra weight so it reaches its cap first, being the widest content and the
column most often actually read; the local pane's NAME carries the remote's
PERMS weight folded into it, which is what makes SIZE and MODIFIED come out the
same width on both sides of the arrow column. Timestamps.Format already argued
that both panes write a time the same way so the two can be read against each
other, and two different widths would have made that argument for nothing.

◆ THE HEADINGS RAN TOGETHER, and that was visible as one word: SIZE ended on
the pixel MODIFIED began at, so the row read "SIZEMODIFIED". They are
right-aligned in their own columns, so the gap has to come from a left margin
on each — which does not move the label and does stop the column before it
reaching this one. The three now carry one, and ellipsize rather than clip
where even the label has no room.

◆ TWO PLACEHOLDERS WERE CUT OFF MID-WORD, which reads as a rendering fault
rather than as a hint. MKDIR's box drew "new directo" — 101 pixels of text in
74 pixels of room — and says "directory" now, since the button beside it
carries the "new" half already. The pane header's path box drew a path ending
mid-segment at the narrow budget and says "path": the only time that
placeholder shows is on a pane with nothing connected, where the box is
disabled and the invitation below is doing the explaining, and what the box is
for is in its tooltip where there is room for it.

FOUR COPIES OF THE COLUMN DEFINITIONS, one heading row and one row template per
pane. Avalonia cannot share a ColumnDefinitions instance between two Grids —
each mutates its own computed sizes — and SharedSizeGroup only applies to Auto
columns, so what catches a copy that drifts is measurement rather than
discipline: every cell is held against the width its own text needs when
unconstrained, the headings against each other, and NAME against zero at the
narrowest budget. Nothing asserts a number this file also wrote down, which is
the failure mode a test of a layout most easily has.

The roomy end is measured at the width a maximised 1843-pixel window leaves,
which is where this was reported from; LayoutHarness.SessionScreenWidth cannot
express it because that constant is pinned to the window's minimum, so the
arithmetic is spelled out beside the test that uses it.
2026-08-21 14:01:45 +02:00
jaap-jan 882f01c515 Type a path on the SFTP pane, and put a file right without deleting it
ci / desktop nightly (pull_request) Skipped
ci / api image (pull_request) Successful in 23s
ci / android head (push) Successful in 3m27s
ci / desktop nightly (push) Successful in 53s
ci / build and test (pull_request) Successful in 2m30s
ci / android head (pull_request) Successful in 7m21s
ci / build and test (push) Successful in 2m28s
ci / api image (push) Successful in 36s
Three things the file browser could not do. Somewhere to go had to be walked
to, a file that landed under the wrong name could only be removed and sent
again, and the listing went on showing the directory as it was before this
application put something in it.

◆ THE PATH IS A BOX NOW, not a TextBlock printing where the pane was. A
breadcrumb only reaches what is under the directory already listed, so crossing
a host's filesystem cost a click and a round trip a level, and a path somebody
already knew could not be entered at all. Enter goes; Escape puts back what the
pane is really showing.

What is typed may be absolute, relative to the directory showing, or start at
~ — the four shapes a shell takes, because somebody typing into a box is typing
what they would type into a shell. SftpPath.Resolve turns all of them into one
absolute path, and it resolves them here rather than handing a relative path to
the server: the server would resolve it against the session's own working
directory, which is not necessarily the directory the breadcrumb above the box
is showing. `..` is collapsed textually, which differs from cd through a
symbolic link; the alternative is a realpath round trip before anything lists.

The box holds its own value rather than RemotePath itself. Binding it straight
to the path would navigate on every keystroke — `/`, then `/v`, then `/va` — a
round trip and a failed listing per character. Every other way of moving writes
the real path back into it; a refused listing deliberately does not, because
the path that did not resolve is the one worth having in front of you.

◆ RENAME AND MOVE, and DELETE moves to join them. It had been sitting in the
pane header beside UP and REFRESH — two things that move the pane and one that
destroys a file, in one row — and the three that act on the selected row are
now together in a row of their own, under the name of the row they are about.

One SFTP rename underneath both new operations and two separate questions on
the screen, because the answer is a different kind of thing each time: a rename
takes a name and must not take a path, a move takes a directory and must not
take a name. One box asking for a destination path would be fewer controls and
a worse question — the two mistakes it invites are exactly the ones the split
makes impossible. Each form opens on the answer that changes nothing, so what
gets edited is the half somebody came to change.

Three refusals are made here, and they are the ones a server's message would
not explain: a separator in a name (no such file, about a directory nobody
meant to name), a destination equal to the source (success, and a file that did
not move), and a directory into itself (EINVAL, true and useless). Everything
else is the server's — a name already taken, a path that is not there, a mount
that cannot be crossed — and arrives in the status line in its own words.
Neither is painted in the deletion card's red: a rename is undone by renaming
back, and spending that red twice makes it stop meaning anything.

◆ THE LISTING REFRESHES ITSELF when a transfer lands in it. Both panes, since
an upload lands on the host and a download lands here and either leaves the
pane that is showing that directory a step behind. Only the directory actually
on screen: a queue moving a hundred files elsewhere must not be a round trip
per file for a listing nobody is looking at.

It waits rather than interrupting. Another operation running would have two
listings racing for one collection, and re-listing under an open question is
how the row somebody answered about stops being the row that gets acted on — so
the staleness is remembered and settled at the end of the operation or when the
question is dismissed. It says nothing either way: nobody asked for it, and the
status line at that moment is carrying the news about the transfer. The
selection survives, re-found by path, which is what makes an unasked-for
refresh safe to run under somebody's pointer at all.

◆ THE LAYOUT SUITE FOUND A REAL FAULT and the fix is where the height goes. The
rename form did not fit the 204 pixels the session shell's own sidebar leaves
this pane — MKDIR and the listing were pushed off the bottom. The form is
shorter now (the placeholder says what the box wants, so there is no field
label above it), and the item row and the breadcrumb step aside while any of
the three questions is up, which is what the phone head already did with its
own buttons.

Measuring also settled something the markup had been claiming and is not true:
at that width the listing collapses to nothing under any of the three cards,
the deletion card included, and has done since the sidebar arrived. So "the row
it is about is still on screen" is retired from the deletion card's remark, and
the full path each card carries is what identifies the row instead. Recorded
where it is drawn rather than left to be rediscovered.

TESTS. SftpPath.Resolve gets the four shapes, ~ with and without a home to
expand it to, a blank box, and climbing past the root. ShellFlowTests gets nine
against a session that records what it was asked to do — which path was
renamed, which directories were listed — rather than against the sentence this
code writes about itself: the path box absolute and relative, rename in place,
the separator refusal, a move by relative path, the no-op refusal, the three
questions displacing each other, and the three rules the automatic refresh
follows. The local half is in TransferQueueingTests, where a real folder
answers. Two new shapes are measured, and the deletion card's own measurement
moves to the connected state — the only state it can be asked in, and the
narrow one.

What the tests cannot reach is in docs/manual-checks.md as phase 2b: a real
server's cross-device and name-taken refusals, and a soft keyboard, which is
why the phone's path box has a GO button rather than trusting whatever the IME
decided to draw on its return key.
2026-08-21 12:05:33 +02:00
jaap-jan 2f8daacb60 Merge pull request 'Reconnect the terminal view when somebody comes back to it' (#14) from claude/terminal-reconnection-stuck-4e57ff into main
ci / build and test (push) Successful in 2m47s
ci / desktop nightly (push) Successful in 46s
ci / android head (push) Successful in 3m47s
ci / api image (push) Successful in 33s
Reviewed-on: #14
2026-08-14 14:13:28 +00:00
jaap-jan ef12e8cc99 Stop the data plane's tests racing the socket they just connected
ci / build and test (pull_request) Successful in 2m30s
ci / android head (pull_request) Successful in 3m19s
ci / desktop nightly (pull_request) Skipped
ci / api image (pull_request) Successful in 21s
CI went red on the run that added the renderer tests, and not on anything they
assert: TerminalDataPlaneTests.Output_ReachesTheRenderer read the output frame
where it expected the session's opening one, having lost a race that has been
in the helper since it was written.

Connected and attached are two different moments. ClientWebSocket.ConnectAsync
completes on the 101, which UpgradeAsync writes before it has a WebSocket to
attach — it builds one from the stream and swaps it in a few instructions
later, on the accept thread. SendAsync drops anything sent in between, which is
the transport's documented contract rather than a bug: there is nowhere to put
a frame for a renderer that is not there, and queueing it is the unbounded
growth the credit window exists to prevent. So a helper that returned on the
handshake and let its caller send immediately was betting on thread scheduling,
every run, on every test in the file.

It only started losing now because that assembly grew nine tests and a
JavaScript engine to run them in, which is more work in parallel with a window
measured in instructions. The race is older than the branch that exposed it.

ConnectAsync now waits for the plane's own SocketAttached, subscribed before
the connection because the event can be over before ConnectAsync returns, and
bounded so a socket that never attaches fails the helper instead of hanging the
suite in a later receive. TerminalWorkspaceTests.ConnectRendererAsync has the
same exposure through OpenSessionAsync's opening frame and now waits on
WaitForRendererAsync, with a note on why that is enough for the reattach tests
and what would stop being enough.

◆ NOTHING IN src CHANGED, AND THAT IS THE CONCLUSION RATHER THAN THE SHORTCUT.
Production waits for exactly this moment already — every path that opens a
session goes through TerminalWorkspace.WaitForRendererAsync, which resolves
from the same few lines that raise the event this helper now waits on. Only the
tests skipped the gate the application does not.

Verified by widening the window rather than by hunting the flake: a 100ms delay
inserted between the 101 and the attach, in a throwaway tree, hangs the old
helper outright — both frames dropped, the test blocked in receive — and passes
89/89 with this one. Green three times over on the CI platform besides
(Alpine, musl, Release, dotnet/sdk:10.0-alpine).
2026-08-14 15:44:03 +02:00
jaap-jan 963cb7f670 Reconnect the terminal view when somebody comes back to it
ci / build and test (pull_request) Failing after 2m29s
ci / desktop nightly (pull_request) Skipped
ci / api image (pull_request) Skipped
ci / android head (pull_request) Successful in 3m23s
Going back to a terminal left alone for a while found it stuck on
"Reconnecting the terminal view…", and stuck is the right word: the banner
stayed and nothing behind it was reconnecting.

The page's whole recovery story was a setTimeout chain, and a chain is exactly
what a WebView is entitled to stop running. Chromium throttles timers in a page
nobody is looking at — down to once a minute once it has been hidden five
minutes — and a renderer that is frozen, or reclaimed and not yet reloaded,
runs none of them. So the socket drops while nobody is watching, the banner
goes up, the retry is scheduled, and the retry is then the one thing not
running.

Three defects, each of which leaves that banner up for the rest of the page's
life.

◆ NOTHING LISTENED FOR THE PAGE COMING BACK. The only thing that could clear
the banner was a timer that may never fire. terminal.js now reconnects on
visibilitychange, focus and online — the events that mean somebody is looking
again, and the ones that cannot be throttled — cancelling the pending timer and
resetting the backoff. Over a healthy socket all three do nothing, which is
what makes them safe to fire as often as clicking a window does.

◆ A HANDSHAKE THAT NEVER FINISHED WAS INVISIBLE. Every retry was scheduled by a
close or an error, so an attempt parked in CONNECTING — which is what a
suspended renderer leaves behind — scheduled nothing at all, ever. There is now
a five-second watchdog on the handshake.

◆ STALE SOCKETS SCHEDULED RETRIES, AND THAT ONE IS A LOOP RATHER THAN A STALL.
connect() never detached the old socket's handlers, and the host aborts the
displaced socket on takeover — TerminalDataPlane.UpgradeAsync, doing exactly
what it should. That close read as a fresh failure and scheduled a retry
against the socket that had just succeeded, whose own close scheduled the next:
no fixed point, reconnecting every second forever with the banner up for most
of it. Every handler now asks whether it is still the page's own attempt, and
connect() closes what it abandons.

◆ WHICH OF THE PLATFORM BEHAVIOURS ACTUALLY BIT IS NOT ESTABLISHED, and the fix
does not depend on knowing. Throttled timers, a frozen renderer and a reclaimed
one all end at the same dead timer; guessing between them would have produced a
narrower fix for one of the three.

THE TEST RUNS terminal.js ITSELF, in a fake browser, inside dotnet test.
RendererPage loads the file the shell project ships — not a transcription of its
logic into C#, which would be a copy that stays correct while the page rots —
into a Jint engine, one per test, over a harness that fakes a WebSocket and a
clock and nothing else. Jint rather than a node script because CI would run the
node one and nobody's inner loop would; the cost is that Jint is not Chromium,
so this proves the page's logic and nothing about how a WebView behaves. That
line is drawn in RendererPage's remark and picked up by two new manual checks,
1.10 for the desktop and 11.12a for the phone, which own the platform half.

Four of the nine tests fail against the page as it stood — the stale close, the
parked handshake, and the two wake-ups. Two more assert that a wake-up over a
healthy socket does nothing, and pass against either version on purpose: they
are what stops the cure being worse.

Left alone deliberately: a socket that is open and dead shows no banner at all,
because readyState still reads OPEN. That looks like a terminal that swallows
what is typed, needs a liveness probe rather than a faster retry, and is written
down at the end of 11.12a rather than quietly bundled in here.
2026-08-14 15:09:43 +02:00
jaap-jan 68964d8a34 Merge pull request 'Name a quick-connect result's vault, and search on it' (#13) from claude/search-items-vault-display-865eb0 into main
ci / build and test (push) Successful in 3m42s
ci / api image (push) Successful in 37s
ci / android head (push) Successful in 3m46s
ci / desktop nightly (push) Successful in 44s
Reviewed-on: #13
2026-08-14 09:13:16 +00:00
jaap-jan fdea3911c1 Name a quick-connect result's vault, and search on it
ci / build and test (pull_request) Failing after 7s
ci / desktop nightly (pull_request) Skipped
ci / api image (pull_request) Skipped
ci / android head (pull_request) Failing after 6s
Ctrl+K reaches every vault the session holds a key for — that is deliberate,
and it is what makes the palette worth opening from anywhere. What it did not
do was say where a result came from. A team and a person who both call a
machine prod-db got two identical rows, and Enter took whichever the ranking
happened to put first: the same three characters, two different machines,
depending on nothing anybody could see.

Nothing new is computed for this. HostRowViewModel.VaultBadge has been filled
in since the host list learned to span vaults, and it is already drawn on the
hosts board, the keychain, the snippets list and the known-hosts pane. The
palette was the one list reaching across every vault that did not print it.

◆ THE VAULT IS THE LAST OF THE FOUR RANKS, AND THAT IS THE POINT. A vault name
is the widest reading of the three the palette had: one word matches every host
in that vault at once, where a name or an address matches one machine. So it
sits behind name-starts-with, name-contains and address — otherwise typing a
machine's name would bury it under everybody else's.

It matches on HasVaultBadge rather than on VaultName, so the search only ever
matches what the row actually shows. A session holding one vault prints no
vault on any row, and matching it there would answer "personal" with the entire
keychain, ranked behind nothing and explained by nothing on screen.

In the row, the right-hand column becomes two lines against the two on the
left, in the same order: what this is above, how it is reached below. With one
vault the badge is empty, the line collapses, and the kind word stays centred
exactly where it was. The name is capped and ellipsised because that column is
Auto-sized — a long vault name would otherwise take its width out of the host
name beside it.

Three tests, one per claim. VaultSharingTests puts platform-gateway in the
personal vault and prod-db in "Platform secrets" and types "platform": both come
back, the gateway first. ShellFlowTests types the personal vault's own name into
a one-vault session and gets nothing. QuickConnectTests is the markup's half —
the shared vault's row draws PLATFORM SECRETS, and a one-vault row draws no
vault at all — with the shared vault put into the session through the layout
suite's own StubTeamServer, as the settings pages' suite does it.

449 App tests and 155 layout tests pass. Both suites were run with
-p:NuGetAudit=false: SSH.NET 2025.1.0 has picked up GHSA-q939-rpr3-3284 and
NU1903 fails restore repo-wide, which predates this branch and is nothing to do
with it. No package or lock file is touched here.
2026-08-14 09:35:44 +02:00
24 changed files with 2908 additions and 74 deletions

No files matched your search

+15
View File
@@ -221,5 +221,20 @@
mistakes that cause real authorization holes.
-->
<PackageVersion Include="WireMock.Net" Version="2.13.0" />
<!--
A JavaScript interpreter, in managed code, so that terminal.js can be tested as the file that
ships rather than as a transcription of it into C#. Test-only and referenced by exactly one
project; nothing in src depends on it.
Chosen over shelling out to node, which is the obvious alternative and needs node present
wherever the suite runs — CI installs one already, but a test that only runs when a separate
command is remembered is a test that stops being run. Chosen over a headless browser for the
same reason several times over.
What it does not buy: Jint is not Chromium, so this proves the page's own logic and nothing
about how WebView2 or Android's WebView behave. That line is drawn in RendererPage's remark and
picked up by docs/manual-checks.md 1.10 and 11.12a.
-->
<PackageVersion Include="Jint" Version="4.16.0" />
</ItemGroup>
</Project>
+125
View File
@@ -171,6 +171,32 @@ bound to the same side of `IsImportOpen`. SettingsNav lighting a different row w
over the importer would be a guard added to `OnKeyDown` for `IsSettingsMode` that the design never asked for
and this application's own quick-connect card was built to reach past.
### 1.10 A terminal left alone for a long time is still a terminal · **needs an hour, or a debugger**
Open a shell, leave the terminal for another screen — HOSTS, FILES, anything — and leave the application
alone for long enough that the window has been in the background for the better part of an hour. Locking the
machine or letting it sleep counts and is the easier way to get there. Come back and click the session's
tab.
**Pass:** the pane is exactly where it was and takes input straight away. If anything is shown at all it is
`Reconnecting the terminal view…` for a moment, in the second or so before the socket is back — never a
status that is still there after that.
**Both of the page's own rules here are covered by `RendererReconnectionTests`**, which runs `terminal.js`
itself in a fake browser — so a failure of this check is more likely to be the WebView behaving unlike that
fake than the page's logic being wrong. That is exactly the division: the test owns the logic, this owns the
platform.
**Failure means:** a banner that stays up is the page's retry not running. It is a `setTimeout` chain, and a
chain is what a WebView is entitled to throttle or freeze while nobody is looking at the page; `terminal.js`
answers that with wake-ups on `visibilitychange`, `focus` and `online`, none of which can be throttled,
plus a watchdog for a handshake that never finishes. A banner that flickers on and off every second or two
instead is the opposite fault — a reconnect loop, in which each attempt displaces the socket before it
through `TerminalDataPlane.UpgradeAsync`'s takeover and the displaced socket's close schedules the next.
That is what the "is this still the page's socket" guard in `connect()` exists to stop. A pane that takes no
input while the banner is *clear* is neither: the socket is open and dead, which nothing on this page can
currently see — see the note at the end of 11.12a.
---
## Phase 2 — Known Hosts as its own page
@@ -401,6 +427,82 @@ surface. Use the ← button, or drag the file to the local pane first.
---
## Phase 2b — The path box, and what can be done to a remote row
The rules are automated — `SftpPath.Resolve` in `RemotePathTests`, the three questions and the automatic
refresh in `ShellFlowTests`, both new shapes measured in `ScreenLayoutTests`. What is left here is what
those cannot reach: a real server's own refusals, and a soft keyboard.
Connect the SFTP page to a host first.
### 2.20 Typing a path
Click into the path in the remote pane's header, type `/var/log`, press Enter. Then type `..`, Enter. Then
`~`, Enter.
**Pass:** each one lists, the breadcrumb underneath follows, and the box ends up showing the absolute path
that was actually reached rather than what was typed.
### 2.21 Escape puts the path back
Type nonsense into the box without pressing Enter, then press Escape.
**Pass:** the box goes back to the directory the pane is showing.
### 2.22 A path the server refuses
Type a path that does not exist, and one that exists but is not readable by this account.
**Pass:** the pane stays where it was, the status line at the foot of the screen carries the server's own
message, and the box still holds what was typed so it can be corrected.
### 2.23 Rename
Select a file, press the rename button, change the name, press RENAME.
**Pass:** the listing comes back with the new name and the row still selected. Then try a name that another
file in the directory already has: **the server refuses it and says so, and nothing is overwritten** — this
is the one that matters, because the whole queue's "nothing lands at its final name until it is complete"
promise rests on the same server behaviour.
### 2.24 Move
Select a file, press the move button, type a directory — try an absolute one and a relative one — and press
MOVE.
**Pass:** the file leaves the listing and is in the directory that was typed.
Then try one across a filesystem boundary on the same host — `/tmp` to a path on a separate mount is the
usual pair. **Pass:** the server refuses with its own message about a cross-device link. This cannot be
faked in a test and is the refusal somebody will eventually meet.
### 2.25 The listing refreshes itself after an upload
Upload a file into the directory showing.
**Pass:** it appears in the remote listing without REFRESH being pressed. Then upload into a *different*
directory: nothing on screen changes. Then download a file into the folder the local pane is showing, and
that one appears on the left the same way.
### 2.26 A transfer that lands while a question is open
Start an upload into the directory showing, and while it runs select a row and press DELETE so the question
is up when the transfer finishes.
**Pass:** the listing does not move while the question is on screen, and refreshes the moment the question
is answered or cancelled.
**Failure means:** the row the question was asked about is not necessarily the row that gets acted on.
### 2.27 The phone's GO button
On Android, connect on the Files screen, type a path into the box above the breadcrumb and press GO.
**Pass:** it lists. The keyboard's own return key may or may not commit — that is the IME's choice, which is
why GO exists — but GO always must.
---
## Phase 3 — Host groups and snippets
Two synced item kinds, two ways of drawing a group — the desktop's grid of cards, one level at a time, and
@@ -1797,6 +1899,29 @@ worse than saying nothing: the banner exists so this is never silently wrong. If
banner is there, the session's credit window was not reset on reattach and the shell is frozen behind it —
see `TerminalWorkspace.ReplayAfterAttachAsync`.
### 11.12a Coming back to a terminal screen left alone for a long while
The same shape as 11.12 and a different trigger: rather than backgrounding the app, stay in it. With a shell
open, leave the terminal for HOSTS, FILES or MORE — which collapses the renderer to GONE, so the page is
hidden by Chromium's reckoning — and leave the phone alone for at least ten minutes with the screen off.
Then come back to the app and to the terminal.
**Pass:** the pane is there and takes input at once, or reconnects visibly within about a second of the
screen appearing. `Reconnecting the terminal view…` on the way in is fine; still being there once the
terminal has been on screen for a couple of seconds is not.
**Failure means:** the page's retry did not survive being hidden. A hidden WebView has its timers throttled
— once a minute after five minutes hidden — and a renderer that was frozen or reclaimed runs none of them,
which is why `terminal.js` does not rely on the timer alone: `visibilitychange` is the event that says the
screen is back, and it reconnects immediately rather than waiting to be asked twice. Ten minutes is chosen
to clear the five-minute threshold with room to spare.
**Not covered by either check, and worth knowing:** a socket that is *open and dead* — the connection gone
without either end noticing, which a suspended renderer can leave behind — shows no banner at all, because
`readyState` still reads OPEN and nothing on this page probes further. The symptom is a terminal that looks
connected and swallows what is typed. If that is ever seen, it is a different bug from this one and needs a
liveness probe rather than a faster retry.
---
## Phase 12 — Shared vaults: the operations that span two accounts
@@ -48,7 +48,7 @@
the refusal has no continue button here either.
-->
<Grid RowDefinitions="Auto,Auto,Auto,Auto,Auto,*,Auto">
<Grid RowDefinitions="Auto,Auto,Auto,Auto,Auto,Auto,*,Auto">
<!-- ============ header ============ -->
<Grid Grid.Row="0" ColumnDefinitions="Auto,Auto,*,Auto" Height="56" Margin="8,0">
@@ -174,8 +174,31 @@
</StackPanel>
</Border>
<!-- ============ ◆ typing where to go ============ -->
<!--
The breadcrumb below reaches only what is under the directory already listed, so crossing a host's
filesystem was a tap and a round trip a level and a path somebody already knew could not be entered at
all. This is the way in for one that is: absolute, relative to the directory showing, or starting at
~. See SftpPath.Resolve.
GO is a real button rather than only the keyboard's own action key, and that is a phone decision: a
software keyboard's return key is whatever the IME decided to draw, this application does not set the
IME action, and a path box whose only commit was a key that may say "newline" would be a box nothing
could be submitted from. The Enter binding stays for the hardware keyboards this head does meet.
-->
<Grid Grid.Row="3" ColumnDefinitions="*,8,Auto" Margin="14,0,14,6" IsVisible="{Binding IsConnected}">
<TextBox Grid.Column="0" Classes="field" Text="{Binding RemotePathDraft}"
PlaceholderText="/path/to/somewhere">
<TextBox.KeyBindings>
<KeyBinding Gesture="Enter" Command="{Binding GoToTypedRemotePathCommand}" />
</TextBox.KeyBindings>
</TextBox>
<Button Grid.Column="2" Classes="secondary" Height="44" Padding="16,0" Content="GO"
Command="{Binding GoToTypedRemotePathCommand}" />
</Grid>
<!-- ============ where we are ============ -->
<ScrollViewer Grid.Row="3" HorizontalScrollBarVisibility="Auto" VerticalScrollBarVisibility="Disabled"
<ScrollViewer Grid.Row="4" HorizontalScrollBarVisibility="Auto" VerticalScrollBarVisibility="Disabled"
IsVisible="{Binding IsConnected}" Margin="0,0,0,4">
<StackPanel Orientation="Horizontal" Spacing="4" Margin="14,0" VerticalAlignment="Center">
<Button Classes="row" MinHeight="36" Padding="9,0" CornerRadius="10"
@@ -215,7 +238,7 @@
answers: an empty scrolling strip under the breadcrumb would read as a loading row rather than as
"this host has nothing pinned".
-->
<ScrollViewer Grid.Row="4" HorizontalScrollBarVisibility="Auto" VerticalScrollBarVisibility="Disabled"
<ScrollViewer Grid.Row="5" HorizontalScrollBarVisibility="Auto" VerticalScrollBarVisibility="Disabled"
IsVisible="{Binding HasConnectedPins}" Margin="0,0,0,4">
<ItemsControl ItemsSource="{Binding ConnectedPinnedPaths}">
<ItemsControl.ItemsPanel>
@@ -240,7 +263,7 @@
</ScrollViewer>
<!-- ============ the listing ============ -->
<Panel Grid.Row="5">
<Panel Grid.Row="6">
<TextBlock Classes="body" IsVisible="{Binding !IsConnected}" Margin="24,12"
VerticalAlignment="Top" Text="{Binding Status}" />
@@ -306,7 +329,7 @@
<!-- ============ what to do with the chosen entry ============ -->
<!-- DeepChrome rather than Chrome, since v5 — see the remark on PhoneShell's vault header. -->
<Border Grid.Row="6" IsVisible="{Binding IsConnected}" Background="{StaticResource DeepChrome}"
<Border Grid.Row="7" IsVisible="{Binding IsConnected}" Background="{StaticResource DeepChrome}"
BorderBrush="{StaticResource Border}" BorderThickness="0,1,0,0" Padding="12,10">
<StackPanel Spacing="9">
@@ -328,6 +351,36 @@
</StackPanel>
</Border>
<!--
◆ Renaming and moving, in the place the deletion question already occupies and never at the same
time as it. One form for both — see RemoteMoveRequest for why the two questions share a shape and
differ only in their words — and no danger colours on it, because a rename is undone by renaming
back and the deletion above is the one thing here that nothing can walk back.
-->
<Border IsVisible="{Binding IsMovingRemote}" Background="{StaticResource Raised}"
BorderBrush="{StaticResource Border}" BorderThickness="1" CornerRadius="12"
Padding="13,11">
<StackPanel Spacing="6">
<TextBlock Classes="mono" FontSize="12" TextWrapping="Wrap"
Text="{Binding PendingRemoteMove.Question}" />
<TextBlock Classes="detail" TextWrapping="Wrap" Text="{Binding PendingRemoteMove.FullPath}" />
<TextBox Classes="field" Text="{Binding RemoteMoveTarget}"
PlaceholderText="{Binding PendingRemoteMove.FieldHint}">
<TextBox.KeyBindings>
<KeyBinding Gesture="Enter" Command="{Binding ConfirmMoveRemoteCommand}" />
</TextBox.KeyBindings>
</TextBox>
<TextBlock Classes="body" Text="{Binding PendingRemoteMove.Note}" />
<Grid ColumnDefinitions="*,8,*" Margin="0,4,0,0">
<Button Grid.Column="0" Classes="primary" Height="44"
Content="{Binding PendingRemoteMove.ConfirmLabel}"
Command="{Binding ConfirmMoveRemoteCommand}" IsEnabled="{Binding !IsBusy}" />
<Button Grid.Column="2" Classes="secondary" Height="44" Content="CANCEL"
Command="{Binding CancelMoveRemoteCommand}" />
</Grid>
</StackPanel>
</Border>
<!--
◆ The queue, above the actions and only when it has something in it. Bounded and scrolling rather
than growing: five files queued must not push the buttons off the bottom of the screen, which on a
@@ -386,20 +439,32 @@
save picker names one destination. CanDownload is the desktop's own flag for the same question —
a file is selected and something is connected — and is reused rather than restated here.
-->
<Grid ColumnDefinitions="*,8,*" IsVisible="{Binding !IsConfirmingRemoteDeletion}">
<Grid ColumnDefinitions="*,8,*" IsVisible="{Binding !IsAskingAboutRemoteEntry}">
<Button Grid.Column="0" Classes="primary" Height="44" Content="ADD FILES" Click="OnAddFiles" />
<Button Grid.Column="2" Classes="secondary" Height="44" Content="SAVE FILE" Click="OnSaveFile"
IsEnabled="{Binding CanDownload}" />
</Grid>
<Grid ColumnDefinitions="*,8,*" IsVisible="{Binding !IsConfirmingRemoteDeletion}">
<!--
◆ The two that put a file right rather than taking it away, above the row DELETE is on and away
from it. Both open a form in place of these buttons — see the card above — because a phone has
nowhere to put a text field except where something else already was.
-->
<Grid ColumnDefinitions="*,8,*" IsVisible="{Binding !IsAskingAboutRemoteEntry}">
<Button Grid.Column="0" Classes="secondary" Height="44" Content="RENAME"
Command="{Binding RenameRemoteCommand}" IsEnabled="{Binding CanRenameRemote}" />
<Button Grid.Column="2" Classes="secondary" Height="44" Content="MOVE"
Command="{Binding MoveRemoteCommand}" IsEnabled="{Binding CanMoveRemote}" />
</Grid>
<Grid ColumnDefinitions="*,8,*" IsVisible="{Binding !IsAskingAboutRemoteEntry}">
<Button Grid.Column="0" Classes="secondary" Height="44" Content="DELETE"
Command="{Binding DeleteRemoteCommand}" IsEnabled="{Binding CanDeleteRemote}" />
<Button Grid.Column="2" Classes="secondary" Height="44" Content="CLOSE"
Command="{Binding DisconnectCommand}" />
</Grid>
<TextBlock Classes="body" IsVisible="{Binding !IsConfirmingRemoteDeletion}"
<TextBlock Classes="body" IsVisible="{Binding !IsAskingAboutRemoteEntry}"
Text="ADD FILES picks documents to send. SAVE FILE asks where the selected file should be kept — the file is created there when you choose it, so a transfer that fails leaves it empty." />
<TextBlock Classes="detail" Foreground="{StaticResource TextDim}" TextWrapping="Wrap"
+35
View File
@@ -828,6 +828,41 @@
<Setter Property="BorderThickness" Value="1.5" />
</Style>
<!--
◆ THE FILE PANE'S PATH BOX, which used to be a TextBlock.
The SFTP pane's header printed where it was and gave no way to say where to go: reaching a directory
the breadcrumb could not see meant walking to a common ancestor and back down, one round trip a level,
and a path somebody already knew could not be typed at all. It is a real TextBox now, and this style
is the whole of what keeps it looking like the label it replaced — no fill and no border until it is
pointed at, the same mono weight and colour the TextBlock carried, and the same height, so a header
that gained an input did not gain a control that shouts about being one.
Declared after the base TextBox rules and after .address for the reason this file keeps restating:
Avalonia has no specificity, so an exception written before the rules it overrides does nothing.
-->
<Style Selector="TextBox.pathbox">
<Setter Property="FontFamily" Value="{StaticResource MonoFont}" />
<Setter Property="FontSize" Value="13.5" />
<Setter Property="FontWeight" Value="Medium" />
<Setter Property="Foreground" Value="{StaticResource TextDim}" />
<Setter Property="MinHeight" Value="26" />
<Setter Property="Padding" Value="6,2" />
<Setter Property="CornerRadius" Value="6" />
</Style>
<Style Selector="TextBox.pathbox /template/ Border#PART_BorderElement">
<Setter Property="Background" Value="Transparent" />
<Setter Property="BorderBrush" Value="Transparent" />
</Style>
<Style Selector="TextBox.pathbox:pointerover /template/ Border#PART_BorderElement">
<Setter Property="Background" Value="{StaticResource Field}" />
<Setter Property="BorderBrush" Value="{StaticResource BorderMid}" />
</Style>
<Style Selector="TextBox.pathbox:focus /template/ Border#PART_BorderElement">
<Setter Property="Background" Value="{StaticResource Field}" />
<Setter Property="BorderBrush" Value="{StaticResource AccentSoft}" />
</Style>
<!--
Lists. The rows in this design are drawn by their own templates and marked as selected with an accent
strip down the left edge, so the theme's rounded blue selection block has to go — it would sit behind
@@ -87,12 +87,27 @@
TextTrimming="CharacterEllipsis" />
</StackPanel>
<!--
Two readings stacked against the two on the left, and in the same order: what this row
IS above, how it is reached below.
◆ THE VAULT, and only when there is more than one to be in — HostRowViewModel.VaultBadge
is empty otherwise, which collapses the line and leaves the kind word centred as it was.
The palette searches every readable vault at once, so without it two hosts a team and a
person both call "prod-db" are two identical rows, and Enter takes whichever the ranking
happened to put first. Trimmed against a cap because the column is Auto-sized: a long
vault name would otherwise take its width out of the host name beside it.
credential / key / password — never the mock's SSH/SFTP kind column. Every palette
connect here is SSH, so printing that word would be a constant dressed up as a reading;
see hosts-v5-design-spec.md's deviations and HostRowViewModel.Authentication.
-->
<TextBlock Grid.Column="2" Classes="mono qcrow-subtext" Text="{Binding Authentication}"
FontSize="11" Margin="10,0,0,0" VerticalAlignment="Center" />
<StackPanel Grid.Column="2" Spacing="1" Margin="10,0,0,0" VerticalAlignment="Center">
<TextBlock Classes="mono qcrow-subtext" Text="{Binding VaultBadge}" FontSize="10"
HorizontalAlignment="Right" MaxWidth="150"
TextTrimming="CharacterEllipsis" IsVisible="{Binding HasVaultBadge}" />
<TextBlock Classes="mono qcrow-subtext" Text="{Binding Authentication}"
FontSize="11" HorizontalAlignment="Right" />
</StackPanel>
</Grid>
</Border>
</DataTemplate>
@@ -33,6 +33,43 @@
layer has not got. See docs/design-import-gaps.md.
-->
<!--
══ THE TWO LISTINGS' COLUMNS ═════════════════════════════════════════════════════════════════════════
◆ They were fixed pixel widths, and fixed was wrong at both ends of the range this screen actually gets.
The numbers — 20/*/60/56 here and 20/*/56/52/48 across the arrow column — were chosen against the 204
pixels the session shell's own QUICK ACCESS sidebar leaves a pane at the window's minimum. Measured,
they were wrong in both directions at once:
· MODIFIED prints "2026-08-21 11:36", which needs 116 pixels, and never had more than 48. So the
column was truncated at every width this screen has ever been drawn at — a maximised window showed
"2026-08" beside a NAME column with four hundred empty pixels in it. PERMS needs 60 for a
ten-character mode and had 48; SIZE needs 58 for "999.9 GB" and had 56.
· At 204 the remote pane's NAME column measured **zero pixels wide**. Twenty for the glyph plus
56+52+48 for the numbers is 176 of the 180 a row has, so the file names — the one column a file
browser exists to show — were not drawn at all.
Star columns with a MaxWidth fix both, because the cap is what makes "share the width" mean the right
thing at each end. Wide, the three numeric columns stop growing at what their own text needs and NAME
keeps every remaining pixel. Narrow, nothing has a MinWidth to overflow with, so all four give ground
together and NAME — weighted heaviest — keeps enough to read a name by.
MODIFIED carries the extra weight (1.6) so that it reaches its cap first: it is the widest content and
the column somebody is most often actually reading. The local pane's NAME is 3* against the remote's 2*,
which is the remote's PERMS weight folded into it — that is what makes SIZE and MODIFIED come out the
same width on both sides of the arrow column, so the same amount of a timestamp is visible in each. See
Timestamps.Format for why both panes write one the same way in the first place; a shared format read at
two different widths would have made that argument for nothing.
◆ FOUR COPIES OF THIS, and they have to stay in step: a heading row and a row template per pane. Avalonia
cannot share one ColumnDefinitions instance between two Grids — each mutates its own computed sizes —
and SharedSizeGroup only applies to Auto columns. What catches a copy that drifts is measurement rather
than discipline: ScreenLayoutTests holds every cell against the width its own text needs
(TheListingColumnsShowTheirContentInFullWhenThereIsRoom), the headings against each other
(TheListingHeadingsDoNotRunIntoEachOther), and NAME against zero at the narrowest budget
(TheNameColumnSurvivesTheNarrowestBudget).
-->
<UserControl.Styles>
<!--
── v5b ─────────────────────────────────────────────────────────────────────────────────────────────
@@ -259,10 +296,18 @@
the row template below for why the whole column set was chosen against 204 pixels rather than the
design's own 1920-pixel canvas.
-->
<Grid Grid.Row="2" ColumnDefinitions="20,*,60,56" Margin="0,2,10,4">
<Grid Grid.Row="2" Margin="0,2,10,4">
<Grid.ColumnDefinitions>
<ColumnDefinition Width="20" />
<ColumnDefinition Width="3*" />
<ColumnDefinition Width="*" MaxWidth="66" />
<ColumnDefinition Width="1.6*" MaxWidth="124" />
</Grid.ColumnDefinitions>
<TextBlock Grid.Column="1" Classes="label" Text="NAME" FontSize="9.5" Margin="8,0,8,0" />
<TextBlock Grid.Column="2" Classes="label" Text="SIZE" FontSize="9.5" HorizontalAlignment="Right" />
<TextBlock Grid.Column="3" Classes="label" Text="MODIFIED" FontSize="9.5" HorizontalAlignment="Right" />
<TextBlock Grid.Column="2" Classes="label" Text="SIZE" FontSize="9.5" Margin="8,0,0,0"
HorizontalAlignment="Right" TextTrimming="CharacterEllipsis" />
<TextBlock Grid.Column="3" Classes="label" Text="MODIFIED" FontSize="9.5" Margin="8,0,0,0"
HorizontalAlignment="Right" TextTrimming="CharacterEllipsis" />
</Grid>
<!--
@@ -274,13 +319,19 @@
SelectedItem="{Binding SelectedLocalEntry}">
<ListBox.ItemTemplate>
<DataTemplate x:DataType="vm:LocalEntryRowViewModel">
<Grid ColumnDefinitions="20,*,60,56" Height="38" Margin="14,0,10,0">
<Grid Height="38" Margin="14,0,10,0">
<Grid.ColumnDefinitions>
<ColumnDefinition Width="20" />
<ColumnDefinition Width="3*" />
<ColumnDefinition Width="*" MaxWidth="66" />
<ColumnDefinition Width="1.6*" MaxWidth="124" />
</Grid.ColumnDefinitions>
<TextBlock Grid.Column="0" Classes="entryicon" Text="{Binding IconGlyph}" />
<TextBlock Grid.Column="1" Classes="mono entry" Classes.dir="{Binding IsNavigable}"
Text="{Binding Name}" FontSize="13.5"
Margin="10,0,8,0" VerticalAlignment="Center" TextTrimming="CharacterEllipsis" />
<TextBlock Grid.Column="2" Classes="mono entrysize" Text="{Binding Size}" FontSize="12"
HorizontalAlignment="Right" VerticalAlignment="Center" />
Margin="8,0,0,0" HorizontalAlignment="Right" VerticalAlignment="Center" />
<TextBlock Grid.Column="3" Classes="mono entrydate" Text="{Binding Modified}" FontSize="12"
Margin="8,0,0,0" HorizontalAlignment="Right" VerticalAlignment="Center" />
</Grid>
@@ -327,10 +378,12 @@
<!-- ==== The host ==== -->
<!--
Six rows rather than five: the connection's own strip is the new one, and it is inside this pane
rather than above both because it is about this pane and nothing else.
Seven rows. Two of them are furniture over a listing rather than part of it: the connection's own
strip, and the row of things that can be done to whichever row is chosen. Both are inside this pane
rather than above both panes because both are about this one and nothing else. The two questions —
deleting, and renaming or moving — share a single row, since only one of the two is ever on screen.
-->
<Grid Grid.Column="2" x:Name="RemotePane" RowDefinitions="Auto,Auto,Auto,Auto,Auto,*"
<Grid Grid.Column="2" x:Name="RemotePane" RowDefinitions="Auto,Auto,Auto,Auto,Auto,Auto,*"
DragDrop.AllowDrop="True">
<!--
@@ -344,25 +397,48 @@
distinct glyphs; see that pane's own remark on why the pair differs without the actions differing.
-->
<!--
The path is alone in the star column for the reason the local pane's header remark spells out:
TextTrimming needs the finite width only a star column gives it, and this is the pane where the
long path is not even unusual — it is any host with a deep directory tree.
◆ THE PATH IS TYPED HERE, and that is what the star column is now holding.
It was a TextBlock printing where the pane was. A breadcrumb only reaches what is under the
directory already listed, so crossing a host's filesystem was a walk to the common ancestor and
back down — a click and a round trip a level — and a path somebody already knew could not be
entered at all. Enter goes; Escape puts back what the pane is really showing. See
TransfersViewModel.RemotePathDraft for why the box holds its own value rather than RemotePath
itself, and SftpPath.Resolve for what an entry that is not absolute means.
Still alone in the star column, for the reason the local pane's header remark spells out: this box
has to be bounded, and an Auto column beside a StackPanel would measure it at its content's width
and push the buttons past the pane's edge.
DELETE has left this row. It acts on the selected row rather than on the pane, and it is one of
three that do now — see the item row below, which is where the three of them are together and
where there is room for three rather than for one.
-->
<Border Grid.Row="0" Padding="0,0,0,10" BorderThickness="0">
<Grid ColumnDefinitions="Auto,*,Auto">
<StackPanel Grid.Column="0" Orientation="Horizontal" Spacing="12" VerticalAlignment="Center"
Margin="0,0,12,0">
Margin="0,0,8,0">
<TextBlock Classes="label" FontSize="10" Text="HOST" VerticalAlignment="Center"
IsVisible="{Binding ShowsHostPicker}" />
<TextBlock Classes="label" FontSize="10" Text="BUCKET" VerticalAlignment="Center"
IsVisible="{Binding ShowsBucketPicker}" />
</StackPanel>
<TextBlock Grid.Column="1" Classes="mono" FontSize="13.5" FontWeight="Medium"
Foreground="{StaticResource TextDim}" VerticalAlignment="Center"
HorizontalAlignment="Left"
Text="{Binding RemotePath}" TextTrimming="CharacterEllipsis"
ToolTip.Tip="{Binding RemotePath}" />
<StackPanel Grid.Column="2" Orientation="Horizontal" Spacing="4" Margin="12,0,0,0">
<TextBox Grid.Column="1" Classes="pathbox" VerticalAlignment="Center"
Text="{Binding RemotePathDraft}" IsEnabled="{Binding IsConnected}"
PlaceholderText="path"
ToolTip.Tip="Type a path and press Enter. A relative path is taken from here; ~ is the account's home directory.">
<!--
One word, because the only time this placeholder shows is on a pane with nothing connected,
where the box is disabled and the invitation below is doing the explaining. "/path/to/
somewhere" needs 146 pixels and had 91 at the session shell's narrowest, so it drew as a
path cut off mid-segment. What the box is for is in the tooltip, where there is room for it.
-->
<TextBox.KeyBindings>
<KeyBinding Gesture="Enter" Command="{Binding GoToTypedRemotePathCommand}" />
<KeyBinding Gesture="Escape" Command="{Binding RevertTypedRemotePathCommand}" />
</TextBox.KeyBindings>
</TextBox>
<StackPanel Grid.Column="2" Orientation="Horizontal" Spacing="4" Margin="8,0,0,0">
<Button Classes="paneicon" Command="{Binding RemoteUpCommand}"
IsEnabled="{Binding IsConnected}" ToolTip.Tip="Up one directory">
<TextBlock FontFamily="{StaticResource IconFont}" FontSize="16" Text="&#xE5DB;" />
@@ -371,10 +447,6 @@
IsEnabled="{Binding IsConnected}" ToolTip.Tip="Refresh">
<TextBlock FontFamily="{StaticResource IconFont}" FontSize="16" Text="&#xE5D5;" />
</Button>
<Button Classes="paneicon danger" Command="{Binding DeleteRemoteCommand}"
IsEnabled="{Binding CanDeleteRemote}" ToolTip.Tip="Delete on the host">
<TextBlock FontFamily="{StaticResource IconFont}" FontSize="15" Text="&#xE872;" />
</Button>
</StackPanel>
</Grid>
</Border>
@@ -402,9 +474,53 @@
</Border>
<!--
The question DELETE asks. Under the button rather than over the pane, so the row it is about is
still on screen and still selected while it is being answered — and it names the full path rather
than the file, because a name is the half that does not identify anything.
◆ WHAT CAN BE DONE TO THE ROW THAT IS CHOSEN. Only while something is connected.
Three buttons in one place, which is the point. DELETE used to sit alone in the pane header beside
UP and REFRESH — two things that move the pane and one that destroys a file, in one row — and
there was no rename and no move at all, so a file that had landed under the wrong name could only
be put right by deleting it and sending it again. These three act on the selection, so they belong
together and away from the two that act on the pane.
The name beside them is the row they are about, ellipsized. It says which row rather than which
path: the listing directly underneath has that row highlighted, so a full path here would be
repeating what the selection is already showing. The forms the buttons open do print the path,
because that is the moment something is committed rather than merely looked at.
The row goes while one of the three questions is up rather than sitting there greyed out, and so
does the breadcrumb below it — see ShowsRemoteItemActions. The form that opens is the answer to
what these buttons asked, and inside the session shell this pane is 204 pixels wide: the height
goes to the question or to the buttons that raised it, not to both.
-->
<Border Grid.Row="2" Padding="12,5" BorderBrush="{StaticResource BorderSubtle}"
BorderThickness="0,0,0,1" IsVisible="{Binding ShowsRemoteItemActions}">
<Grid ColumnDefinitions="*,Auto">
<TextBlock Grid.Column="0" Classes="mono" FontSize="11.5" VerticalAlignment="Center"
Foreground="{StaticResource TextFaint}" TextTrimming="CharacterEllipsis"
Text="{Binding SelectedRemoteName}" />
<StackPanel Grid.Column="1" Orientation="Horizontal" Spacing="4" Margin="8,0,0,0">
<Button Classes="paneicon" Command="{Binding RenameRemoteCommand}"
IsEnabled="{Binding CanRenameRemote}" ToolTip.Tip="Rename on the host">
<TextBlock FontFamily="{StaticResource IconFont}" FontSize="15" Text="&#xE9AD;" />
</Button>
<Button Classes="paneicon" Command="{Binding MoveRemoteCommand}"
IsEnabled="{Binding CanMoveRemote}" ToolTip.Tip="Move to another directory">
<TextBlock FontFamily="{StaticResource IconFont}" FontSize="15" Text="&#xE675;" />
</Button>
<Button Classes="paneicon danger" Command="{Binding DeleteRemoteCommand}"
IsEnabled="{Binding CanDeleteRemote}" ToolTip.Tip="Delete on the host">
<TextBlock FontFamily="{StaticResource IconFont}" FontSize="15" Text="&#xE872;" />
</Button>
</StackPanel>
</Grid>
</Border>
<!--
The question DELETE asks. It names the full path rather than the file, because a name is the half
that does not identify anything — and that is now the whole of how the question says which row it
is about: at the session shell's own 204-pixel width there is no height left for a listing under
it, so "the row is still on screen and still selected" is no longer true and the path in the card
is what carries the identity. See the rename form below, which is measured in the same shape.
This is the strongest warning on any of these screens, and deliberately: everything else this
application deletes is a tombstone against a copy the server still has, and a file on somebody's
@@ -415,7 +531,7 @@
CANCEL side by side want closer to 220, so at the narrow width they wrap onto their own line
instead of one of them going off the edge, which the WrapPanel achieves for free.
-->
<Border Grid.Row="2" Padding="12,10" Background="{StaticResource DangerWash}"
<Border Grid.Row="3" Padding="12,10" Background="{StaticResource DangerWash}"
BorderBrush="{StaticResource DangerSoft}" BorderThickness="0,0,0,1"
IsVisible="{Binding IsConfirmingRemoteDeletion}">
<StackPanel Spacing="7">
@@ -435,7 +551,65 @@
</StackPanel>
</Border>
<Grid Grid.Row="3" ColumnDefinitions="*,Auto" Margin="12,6,12,4">
<!--
◆ RENAME AND MOVE, in the row the deletion question uses and never at the same time as it.
One form for both, because they differ only in what the box starts out holding and in the words
around it — see RemoteMoveRequest, where both sets are chosen. It shares this Grid row with
the deletion card above: the three questions are mutually exclusive by construction, each one's
own opening clearing the others, so a row of its own would be a row that is empty whenever this
one is not.
It is not painted in the deletion card's danger colours, and that is deliberate rather than an
oversight. A rename is undone by renaming back; the deletion beside it is the one thing this
application does that nothing can walk back, and spending the same red on both would make the red
stop meaning anything.
Enter commits from inside the box, which is where the hands already are once an answer has been
typed.
◆ IT TAKES THE WHOLE PANE at the session shell's own 204-pixel width, and that is measured rather
than hoped: the listing's star row is squeezed to nothing while either question is open, exactly
as the deletion card above already squeezed it. There is no room for a form and a listing in 336
pixels, and the form carries the full path precisely so the row underneath does not have to be
visible for the question to be about something identifiable. That is why the item row and the
breadcrumb step aside instead — the height they free is what keeps the form itself un-clipped,
which is what ScreenLayoutTests measures.
-->
<Border Grid.Row="3" Padding="12,10" Background="{StaticResource Raised}"
BorderBrush="{StaticResource BorderSubtle}" BorderThickness="0,0,0,1"
IsVisible="{Binding IsMovingRemote}">
<StackPanel Spacing="7">
<TextBlock Classes="heading" FontSize="14" TextWrapping="Wrap"
Text="{Binding PendingRemoteMove.Question}" />
<SelectableTextBlock Classes="mono" FontSize="11.5" TextWrapping="Wrap"
Foreground="{StaticResource TextFaint}"
Text="{Binding PendingRemoteMove.FullPath}" />
<TextBox Text="{Binding RemoteMoveTarget}"
PlaceholderText="{Binding PendingRemoteMove.FieldHint}">
<TextBox.KeyBindings>
<KeyBinding Gesture="Enter" Command="{Binding ConfirmMoveRemoteCommand}" />
<KeyBinding Gesture="Escape" Command="{Binding CancelMoveRemoteCommand}" />
</TextBox.KeyBindings>
</TextBox>
<TextBlock Classes="hint" FontSize="11.5" TextWrapping="Wrap"
Text="{Binding PendingRemoteMove.Note}" />
<WrapPanel>
<Button Classes="accent" Content="{Binding PendingRemoteMove.ConfirmLabel}" Margin="0,0,8,4"
Command="{Binding ConfirmMoveRemoteCommand}" IsEnabled="{Binding !IsBusy}" />
<Button Classes="ghost" Content="CANCEL" Margin="0,0,0,4"
Command="{Binding CancelMoveRemoteCommand}" />
</WrapPanel>
</StackPanel>
</Border>
<!--
Away while a question is up, for the reason the item row above states: the trail is where the pane
is and MKDIR makes a directory, and neither is what somebody answering a question about one row
is doing.
-->
<Grid Grid.Row="4" ColumnDefinitions="*,Auto" Margin="12,6,12,4"
IsVisible="{Binding !IsAskingAboutRemoteEntry}">
<ItemsControl Grid.Column="0" ItemsSource="{Binding RemoteTrail}" VerticalAlignment="Center">
<ItemsControl.ItemsPanel>
<ItemsPanelTemplate>
@@ -467,10 +641,16 @@
is showing, 140 plus MKDIR plus the spacing between them ran past the pane's own edge. Still wide
enough for a real directory name to be typed and read back, which is what this box is for; a
name that outgrows it scrolls inside the box the way every TextBox already does.
◆ The placeholder says "directory" rather than "new directory", which is what it said until it
was measured: the longer text needs 101 pixels inside a box that has 74, so it drew as "new
directo" — a placeholder cut off mid-word, which reads as a rendering fault rather than as a
hint. MKDIR is right beside it and carries the "new" half already. The path box in the header
above lost the same argument and for the same reason; see its own PlaceholderText.
-->
<StackPanel Grid.Column="1" Orientation="Horizontal" Spacing="6"
IsVisible="{Binding IsConnected}">
<TextBox Width="90" Text="{Binding NewRemoteFolder}" PlaceholderText="new directory" />
<TextBox Width="90" Text="{Binding NewRemoteFolder}" PlaceholderText="directory" />
<Button Classes="ghost" Content="MKDIR" Command="{Binding CreateRemoteFolderCommand}" />
</StackPanel>
</Grid>
@@ -480,25 +660,42 @@
48 pixels rather than the drawer's own wider habit, and SIZE/MODIFIED shrink to match the local
pane's narrower numbers. See the local pane's own remark on why 204 rather than the design's 1920.
-->
<Grid Grid.Row="4" ColumnDefinitions="20,*,56,52,48" Margin="0,2,10,4">
<Grid Grid.Row="5" Margin="0,2,10,4">
<Grid.ColumnDefinitions>
<ColumnDefinition Width="20" />
<ColumnDefinition Width="2*" />
<ColumnDefinition Width="*" MaxWidth="66" />
<ColumnDefinition Width="1.6*" MaxWidth="124" />
<ColumnDefinition Width="*" MaxWidth="66" />
</Grid.ColumnDefinitions>
<TextBlock Grid.Column="1" Classes="label" Text="NAME" FontSize="9.5" Margin="8,0,8,0" />
<TextBlock Grid.Column="2" Classes="label" Text="SIZE" FontSize="9.5" HorizontalAlignment="Right" />
<TextBlock Grid.Column="3" Classes="label" Text="MODIFIED" FontSize="9.5" HorizontalAlignment="Right" />
<TextBlock Grid.Column="4" Classes="label" Text="PERMS" FontSize="9.5" HorizontalAlignment="Right" />
<TextBlock Grid.Column="2" Classes="label" Text="SIZE" FontSize="9.5" Margin="8,0,0,0"
HorizontalAlignment="Right" TextTrimming="CharacterEllipsis" />
<TextBlock Grid.Column="3" Classes="label" Text="MODIFIED" FontSize="9.5" Margin="8,0,0,0"
HorizontalAlignment="Right" TextTrimming="CharacterEllipsis" />
<TextBlock Grid.Column="4" Classes="label" Text="PERMS" FontSize="9.5" Margin="6,0,0,0"
HorizontalAlignment="Right" TextTrimming="CharacterEllipsis" />
</Grid>
<ListBox Grid.Row="5" x:Name="RemoteList" Classes="filerows" ItemsSource="{Binding RemoteEntries}"
<ListBox Grid.Row="6" x:Name="RemoteList" Classes="filerows" ItemsSource="{Binding RemoteEntries}"
SelectedItem="{Binding SelectedRemoteEntry}">
<ListBox.ItemTemplate>
<DataTemplate x:DataType="vm:RemoteEntryRowViewModel">
<Grid ColumnDefinitions="20,*,56,52,48" Height="38" Margin="14,0,10,0">
<Grid Height="38" Margin="14,0,10,0">
<Grid.ColumnDefinitions>
<ColumnDefinition Width="20" />
<ColumnDefinition Width="2*" />
<ColumnDefinition Width="*" MaxWidth="66" />
<ColumnDefinition Width="1.6*" MaxWidth="124" />
<ColumnDefinition Width="*" MaxWidth="66" />
</Grid.ColumnDefinitions>
<TextBlock Grid.Column="0" Classes="entryicon" Text="{Binding IconGlyph}" />
<TextBlock Grid.Column="1" Classes="mono entry" Classes.dir="{Binding IsNavigable}"
Classes.exec="{Binding IsExecutable}"
Text="{Binding Name}" FontSize="13.5"
Margin="10,0,8,0" VerticalAlignment="Center" TextTrimming="CharacterEllipsis" />
<TextBlock Grid.Column="2" Classes="mono entrysize" Text="{Binding Size}" FontSize="12"
HorizontalAlignment="Right" VerticalAlignment="Center" />
Margin="8,0,0,0" HorizontalAlignment="Right" VerticalAlignment="Center" />
<TextBlock Grid.Column="3" Classes="mono entrydate" Text="{Binding Modified}" FontSize="12"
Margin="8,0,0,0" HorizontalAlignment="Right" VerticalAlignment="Center" />
<TextBlock Grid.Column="4" Classes="mono perms" Classes.loose="{Binding IsWorldWritable}"
@@ -513,7 +710,7 @@
A directory with nothing in it. It no longer has to say anything about not being connected: that
state is the invitation below, which covers this pane whole.
-->
<TextBlock Grid.Row="5" Classes="hint" FontSize="12" Margin="24" MaxWidth="300"
<TextBlock Grid.Row="6" Classes="hint" FontSize="12" Margin="24" MaxWidth="300"
HorizontalAlignment="Center" VerticalAlignment="Center" TextAlignment="Center"
Text="Nothing in this directory." IsVisible="{Binding !HasRemoteEntries}" />
@@ -535,7 +732,7 @@
the picker arrives, so the tall shape is the form rather than form-plus-prose, and neither shape
reaches the floor. Anything added here has to hold that; the layout suite measures both.
-->
<Border Grid.Row="1" Grid.RowSpan="5" Background="{StaticResource Canvas}"
<Border Grid.Row="1" Grid.RowSpan="6" Background="{StaticResource Canvas}"
IsVisible="{Binding !IsConnected}">
<StackPanel Spacing="10" Margin="20" MaxWidth="320"
HorizontalAlignment="Center" VerticalAlignment="Center">
@@ -679,11 +876,11 @@
window that has stopped answering, and the answer arriving after the drop is the answer arriving
too late. See the local pane for why neither may hit-test.
-->
<Border Grid.Row="0" Grid.RowSpan="6" IsHitTestVisible="False"
<Border Grid.Row="0" Grid.RowSpan="7" IsHitTestVisible="False"
Background="{StaticResource AccentWash}" BorderBrush="{StaticResource Accent}"
BorderThickness="2" IsVisible="{Binding IsRemoteDropTarget}" />
<Border Grid.Row="0" Grid.RowSpan="6" IsHitTestVisible="False"
<Border Grid.Row="0" Grid.RowSpan="7" IsHitTestVisible="False"
Background="{StaticResource DangerWash}" BorderBrush="{StaticResource DangerSoft}"
BorderThickness="2" IsVisible="{Binding IsRemoteDropRefused}">
<TextBlock Classes="hint" Text="Connect to a host first." FontSize="12"
@@ -2141,8 +2141,9 @@ internal sealed partial class MainWindowViewModel : ObservableObject, IAsyncDisp
/// <remarks>
/// Ranked rather than merely filtered: a host whose name starts with what was typed comes before one
/// that merely contains it, and both come before a match found only in the address. Typing three
/// characters of a name people use daily should not put that host third.
/// that merely contains it, both come before a match found only in the address, and all three come
/// before one found only in the vault's name. Typing three characters of a name people use daily should
/// not put that host third. See <see cref="Rank"/>.
/// </remarks>
private void RefreshSearchResults()
{
@@ -2175,6 +2176,21 @@ internal sealed partial class MainWindowViewModel : ObservableObject, IAsyncDisp
OnPropertyChanged(nameof(HasSearchResults));
}
/// <summary>Where one host places against what was typed, or <see cref="int.MaxValue"/> for no match.</summary>
/// <remarks>
/// <para>
/// <b>The vault comes last, and only when the row prints it.</b> Its name is the widest of the three
/// readings — one word can match every host in a team's vault at once — so a host whose own name or
/// address answers the query has to come first, or typing a machine's name would bury it under everybody
/// else's.
/// </para>
/// <para>
/// <see cref="HostRowViewModel.HasVaultBadge"/> rather than the name itself, so this matches exactly what
/// the row shows: a session holding one vault prints no vault on any row, and matching a name nothing
/// displays would answer a query with a list whose reason for existing is invisible — type "personal"
/// there and every host comes back for no reason anybody can see.
/// </para>
/// </remarks>
private static int Rank(HostRowViewModel host, string query)
{
if (host.Label.StartsWith(query, StringComparison.CurrentCultureIgnoreCase))
@@ -2187,8 +2203,14 @@ internal sealed partial class MainWindowViewModel : ObservableObject, IAsyncDisp
return 1;
}
return host.Address.Contains(query, StringComparison.CurrentCultureIgnoreCase)
? 2
if (host.Address.Contains(query, StringComparison.CurrentCultureIgnoreCase))
{
return 2;
}
return host.HasVaultBadge
&& host.VaultName.Contains(query, StringComparison.CurrentCultureIgnoreCase)
? 3
: int.MaxValue;
}
@@ -306,6 +306,83 @@ internal sealed record RemoteDeletionRequest(string Name, string FullPath, bool
+ "touched, and there is no undo.";
}
/// <summary>Which of the two things a rename actually is, from where the user is standing.</summary>
/// <remarks>
/// One SFTP operation underneath — <c>ISftpSession.RenameAsync</c> is the whole of both — and two separate
/// questions on the screen, because the answer a person types is a different kind of thing each time. A
/// rename takes a name and must not take a path; a move takes a directory and must not take a name. Folding
/// them into one box asking for a destination path would be fewer controls and a worse question: the two
/// mistakes it invites — typing a directory where a name goes, or a name where a directory goes — are
/// exactly the ones this split makes impossible to make.
/// </remarks>
internal enum RemoteMoveKind
{
/// <summary>Same directory, different name.</summary>
Rename,
/// <summary>Same name, different directory.</summary>
Move,
}
/// <summary>
/// Something on the host that is being given a new name or a new home, and has not been committed yet.
/// </summary>
/// <remarks>
/// <para>
/// The shape <see cref="RemoteDeletionRequest"/> already established, and here for the same reason: it
/// carries the full path rather than the name, so nothing that happens between opening the form and
/// pressing its button can point the operation at a different file. The selection can move underneath it —
/// a refresh nulls it — and the request stays about what was asked about.
/// </para>
/// <para>
/// <b>It asks rather than warns.</b> Renaming and moving on the host are not deletions: what they change is
/// where the bytes are reached from, and both are undone by doing them again the other way. So this form
/// carries a field and a verb instead of <see cref="RemoteDeletionRequest.Consequence"/>'s "there is no
/// undo" — the one warning on this screen that is earned, and worth not spending twice.
/// </para>
/// </remarks>
/// <param name="Name">What the row is called now.</param>
/// <param name="FullPath">Where it is now, which is the end of the operation nothing may re-point.</param>
/// <param name="IsDirectory">Whether it is a directory, which changes what moving it can be asked to do.</param>
/// <param name="Kind">Which question is being asked.</param>
internal sealed record RemoteMoveRequest(string Name, string FullPath, bool IsDirectory, RemoteMoveKind Kind)
{
/// <summary>Whether this is the rename question rather than the move one.</summary>
internal bool IsRename => Kind is RemoteMoveKind.Rename;
/// <summary>The heading, which names the thing rather than only the verb.</summary>
internal string Question => IsRename
? $"Rename '{Name}' on the host"
: $"Move '{Name}' to another directory";
/// <summary>
/// What an empty box shows, which is the shape of the answer rather than an example of one.
/// </summary>
/// <remarks>
/// The placeholder is the whole of what says which of the two kinds of answer the box wants — there is
/// no label above it. A field label would be a second line saying what this line already says, and the
/// pane this form opens in is 204 pixels wide inside the session shell: every line it does not need is
/// a line of the listing underneath that survives.
/// </remarks>
internal string FieldHint => IsRename ? "new name" : "/path/to/directory";
/// <summary>What the button that commits it says.</summary>
internal string ConfirmLabel => IsRename ? "RENAME" : "MOVE";
/// <summary>
/// What it does, in the one sentence the form has room for.
/// </summary>
/// <remarks>
/// Both halves state the refusal rather than the action, because the action is already in the heading
/// and the refusal is the part nobody expects: SFTP's rename does not replace, so a name already taken
/// is a failure rather than a silent overwrite — which is the same promise the transfer queue makes and
/// rests on the same server behaviour.
/// </remarks>
internal string Note => IsRename
? "A name already taken is refused, not overwritten."
: "Relative to the directory showing. A name already taken is refused, not overwritten.";
}
/// <summary>
/// The transfers screen: a host, two directory panes, and the queue between them.
/// </summary>
@@ -382,6 +459,15 @@ internal sealed partial class TransfersViewModel : ObservableObject, IAsyncDispo
private bool disposed;
/// <summary>Whether the remote listing on screen is known to be out of date.</summary>
/// <remarks>
/// Set by <see cref="NoteTransferLanded"/> and cleared by any listing of the directory it is about.
/// Read back by <see cref="RemoteListingIsStale"/>, which exists so that the deferral this drives can be
/// asserted on in the state where it defers — the moment a transfer lands over an open question is not
/// one a test can otherwise see the inside of.
/// </remarks>
private bool remoteListingIsStale;
/// <param name="sftp">Opens SFTP sessions.</param>
/// <param name="clock">Time source, for transfer rates and timestamps.</param>
/// <param name="post">
@@ -706,6 +792,26 @@ internal sealed partial class TransfersViewModel : ObservableObject, IAsyncDispo
internal ObservableCollection<CrumbViewModel> RemoteTrail { get; } = [];
/// <summary>
/// What is in the pane's path box, which is not where the pane is.
/// </summary>
/// <remarks>
/// <para>
/// A draft beside <see cref="RemotePath"/> rather than the path itself made editable, and the two facts
/// really are different: <see cref="RemotePath"/> is the directory that was listed, and this is what
/// somebody is halfway through typing. Binding the box straight to the path would navigate on every
/// keystroke — <c>/</c>, then <c>/v</c>, then <c>/va</c> — which is a round trip and a failed listing
/// per character.
/// </para>
/// <para>
/// It is written back from <see cref="ListRemoteAsync"/>, so every other way of moving — a breadcrumb,
/// UP, a pin, connecting — puts the real path back in the box. What a failed listing leaves is what was
/// typed, on purpose: the path that did not resolve is the one worth having in front of you to correct.
/// </para>
/// </remarks>
[ObservableProperty]
private string remotePathDraft = string.Empty;
[ObservableProperty]
private RemoteEntryRowViewModel? selectedRemoteEntry;
@@ -721,13 +827,75 @@ internal sealed partial class TransfersViewModel : ObservableObject, IAsyncDispo
internal bool IsConfirmingRemoteDeletion => PendingRemoteDeletion is not null;
/// <summary>The rename or move being filled in, or null when none is.</summary>
[ObservableProperty]
private RemoteMoveRequest? pendingRemoteMove;
/// <summary>
/// What has been typed into whichever of the two forms is open — a name, or a directory.
/// </summary>
/// <remarks>
/// One box for both, because only one of the two forms is ever open: they replace each other, and a
/// second field would be a second thing to clear at every place this one is. Seeded from the row when
/// the form opens — the current name for a rename, the current directory for a move — so that both
/// questions start from the answer that changes nothing, and what somebody edits is the part they came
/// to change.
/// </remarks>
[ObservableProperty]
private string remoteMoveTarget = string.Empty;
internal bool IsMovingRemote => PendingRemoteMove is not null;
/// <summary>
/// Whether the pane is waiting on an answer about the selected row.
/// </summary>
/// <remarks>
/// The three item buttons and the automatic refresh all read this rather than the two flags separately.
/// Deleting, renaming and moving are one at a time by construction — each form's own opening clears the
/// other — and what this names is the state where none of them may be started and nothing may pull the
/// listing out from under the question. See <see cref="SettleRemoteListingAsync"/>.
/// </remarks>
internal bool IsAskingAboutRemoteEntry => IsConfirmingRemoteDeletion || IsMovingRemote;
/// <summary>Whether the pane's DELETE is live.</summary>
/// <remarks>
/// Off while its own question is up, so a second press cannot arm a second one behind the card — and
/// disabled rather than hidden, because this button sits in a row of three and a gap where it was would
/// move UP and REFRESH out from under the pointer.
/// Off while any of the three questions is up, so a second press cannot arm a second one behind the
/// form — and disabled rather than hidden, because these buttons sit in a row and a gap where one was
/// would move the other two out from under the pointer.
/// </remarks>
internal bool CanDeleteRemote => IsConnected && !IsConfirmingRemoteDeletion;
internal bool CanDeleteRemote => IsConnected && !IsAskingAboutRemoteEntry;
/// <inheritdoc cref="CanDeleteRemote" />
internal bool CanRenameRemote => CanDeleteRemote;
/// <inheritdoc cref="CanDeleteRemote" />
internal bool CanMoveRemote => CanDeleteRemote;
/// <summary>
/// Whether the pane shows the row of things that can be done to the chosen row.
/// </summary>
/// <remarks>
/// Gone while one of the three questions is up, rather than merely disabled, and the phone head does
/// the same with its own buttons for the same reason: the form is the answer to the question those
/// buttons ask, and a pane 204 pixels wide inside the session shell has to spend the height on one or
/// the other. What is not on screen is not a control somebody can press by mistake either.
/// </remarks>
internal bool ShowsRemoteItemActions => IsConnected && !IsAskingAboutRemoteEntry;
/// <summary>Whether a transfer has landed in the directory showing and it has not been re-read yet.</summary>
/// <remarks>See <see cref="SettleRemoteListingAsync"/> for when that is allowed to be true for a while.</remarks>
internal bool RemoteListingIsStale => remoteListingIsStale;
/// <summary>
/// What the item row says it is about — the chosen row's name, or the sentence that says to choose one.
/// </summary>
/// <remarks>
/// A name rather than a full path, unlike the questions the buttons open: this line sits directly above
/// the listing with the row it names highlighted in it, so the disambiguation a confirmation needs is
/// already on screen. The forms carry the path, because by then the answer is being committed rather
/// than merely looked at.
/// </remarks>
internal string SelectedRemoteName => SelectedRemoteEntry?.Name ?? "Choose a row to act on it";
// ---- The local pane ----
@@ -1199,6 +1367,58 @@ internal sealed partial class TransfersViewModel : ObservableObject, IAsyncDispo
}
}
/// <summary>
/// Goes wherever the path box says.
/// </summary>
/// <remarks>
/// <para>
/// The way out of the breadcrumb's own limit: it can only offer what is under the directory already
/// listed, so crossing the filesystem meant walking down to the root and back up again, a round trip a
/// level. What is typed may be absolute, relative to the directory showing, or start at <c>~</c> — see
/// <see cref="SftpPath.Resolve"/>, which is where all three become one absolute path.
/// </para>
/// <para>
/// A blank box is not a request to go to the root. It puts the current path back and stays where it is:
/// somebody who cleared the box and pressed Enter has not asked for anything, and <c>/</c> is a long way
/// from where they were.
/// </para>
/// <para>
/// Nothing is validated here beyond that. Whether the path exists, is a directory and may be read are
/// three questions only the server can answer, and it answers all three at once by refusing the listing
/// — which lands in the status line with the server's own words in it.
/// </para>
/// </remarks>
[RelayCommand]
private async Task GoToTypedRemotePathAsync(CancellationToken cancellationToken)
{
if (session is not { } open)
{
Status = "Connect to a host first.";
return;
}
if (RemotePathDraft.Trim().Length == 0)
{
RemotePathDraft = RemotePath;
return;
}
var from = RemotePath.Length > 0 ? RemotePath : open.HomeDirectory;
await NavigateRemoteAsync(
SftpPath.Resolve(from, RemotePathDraft, open.HomeDirectory), cancellationToken)
.ConfigureAwait(true);
}
/// <summary>Puts the real path back in the box, for the Escape key.</summary>
/// <remarks>
/// Half-typed text left in a box that says where you are is a box that is lying about where you are, and
/// the pane underneath it goes on showing the directory it always was. Escape is the way out of that
/// without having to remember what was in the box before.
/// </remarks>
[RelayCommand]
private void RevertTypedRemotePath() => RemotePathDraft = RemotePath;
/// <summary>
/// Opens whatever is selected in the remote pane, if it is somewhere to go.
/// </summary>
@@ -1631,6 +1851,9 @@ internal sealed partial class TransfersViewModel : ObservableObject, IAsyncDispo
return;
}
// The other question goes, so the two forms cannot be on screen at once over one row.
PendingRemoteMove = null;
PendingRemoteDeletion = new RemoteDeletionRequest(row.Name, row.FullPath, !row.IsFile);
}
@@ -1666,8 +1889,173 @@ internal sealed partial class TransfersViewModel : ObservableObject, IAsyncDispo
}
/// <summary>Thinks better of it.</summary>
/// <remarks>
/// Settles the listing on the way out. A transfer that landed while the question was up left the pane
/// out of date and was not allowed to refresh it — see <see cref="SettleRemoteListingAsync"/> — so
/// dismissing the question is the moment that refresh becomes safe.
/// </remarks>
[RelayCommand]
private void CancelDeleteRemote() => PendingRemoteDeletion = null;
private async Task CancelDeleteRemoteAsync()
{
PendingRemoteDeletion = null;
await SettleRemoteListingAsync().ConfigureAwait(true);
}
/// <summary>Opens the rename form on the chosen row.</summary>
[RelayCommand]
private void RenameRemote() => AskAboutMoving(RemoteMoveKind.Rename);
/// <summary>Opens the move form on the chosen row.</summary>
[RelayCommand]
private void MoveRemote() => AskAboutMoving(RemoteMoveKind.Move);
/// <remarks>
/// Both forms, because they differ only in what the box starts out holding and what the labels say —
/// see <see cref="RemoteMoveRequest"/>. The rename starts from the current name and the move from the
/// current directory, so each opens showing the answer that changes nothing and what gets edited is the
/// half somebody actually came to change.
/// </remarks>
private void AskAboutMoving(RemoteMoveKind kind)
{
if (SelectedRemoteEntry is not { } row)
{
Status = kind is RemoteMoveKind.Rename
? "Choose something on the host to rename."
: "Choose something on the host to move.";
return;
}
// The other question goes, so the two forms cannot be on screen at once over one row.
PendingRemoteDeletion = null;
PendingRemoteMove = new RemoteMoveRequest(row.Name, row.FullPath, !row.IsFile, kind);
RemoteMoveTarget = kind is RemoteMoveKind.Rename
? row.Name
: SftpPath.Parent(row.FullPath);
}
/// <summary>
/// Carries out whichever of the two was filled in.
/// </summary>
/// <remarks>
/// <para>
/// One SFTP rename underneath both, which is what the protocol offers and the whole of what a move is
/// on one host. It follows that neither works across hosts and neither works across a filesystem
/// boundary on the same host: the server refuses with <c>EXDEV</c>, and that refusal arrives in the
/// status line as the server's own sentence rather than being pre-empted by a guess here about which of
/// its mounts a path is on.
/// </para>
/// <para>
/// It acts on the path the form named rather than on the selection, for the reason
/// <see cref="ConfirmDeleteRemoteAsync"/> does: nothing between opening the form and pressing its button
/// may re-point it at a different file.
/// </para>
/// </remarks>
[RelayCommand]
private async Task ConfirmMoveRemoteAsync(CancellationToken cancellationToken)
{
if (PendingRemoteMove is not { } request)
{
return;
}
if (!TryResolveMoveDestination(request, out var destination, out var refusal))
{
// The form stays open. What was typed is what has to be corrected, and taking the form away
// would take the box holding it as well.
Status = refusal;
return;
}
PendingRemoteMove = null;
await RunAsync(
request.IsRename ? $"Renaming {request.Name}…" : $"Moving {request.Name}…",
async () =>
{
await RequireSession()
.RenameAsync(request.FullPath, destination, cancellationToken)
.ConfigureAwait(true);
await ListRemoteAsync(RemotePath, cancellationToken).ConfigureAwait(true);
Status = request.IsRename
? $"Renamed {request.Name} to {SftpPath.Name(destination)}."
: $"Moved {request.Name} to {SftpPath.Parent(destination)}.";
}).ConfigureAwait(true);
}
/// <summary>Thinks better of it.</summary>
/// <inheritdoc cref="CancelDeleteRemoteAsync" path="/remarks" />
[RelayCommand]
private async Task CancelMoveRemoteAsync()
{
PendingRemoteMove = null;
RemoteMoveTarget = string.Empty;
await SettleRemoteListingAsync().ConfigureAwait(true);
}
/// <summary>
/// Works out where the typed answer actually points, or why it points nowhere.
/// </summary>
/// <remarks>
/// The three refusals here are the ones a server's own error message would not explain. A separator in
/// a name is a move wearing a rename's clothing and the server would simply say "no such file" about a
/// directory nobody meant to name; a destination equal to the source is a request that succeeds while
/// doing nothing; and a directory moved inside itself is <c>EINVAL</c>, which is true and says nothing.
/// Everything else — a path that is not there, a name already taken, a mount that cannot be crossed —
/// is left to the server, which knows and this does not.
/// </remarks>
private bool TryResolveMoveDestination(
RemoteMoveRequest request, out string destination, out string refusal)
{
destination = string.Empty;
var typed = RemoteMoveTarget.Trim();
if (typed.Length == 0)
{
refusal = request.IsRename
? "Type a new name for it."
: "Type the directory to move it into.";
return false;
}
if (request.IsRename)
{
if (typed.Contains('/', StringComparison.Ordinal))
{
refusal = "A name cannot contain '/'. Use MOVE to put it in another directory.";
return false;
}
destination = SftpPath.Combine(SftpPath.Parent(request.FullPath), typed);
}
else
{
var into = SftpPath.Resolve(RemotePath, typed, session?.HomeDirectory);
destination = SftpPath.Combine(into, request.Name);
}
if (string.Equals(destination, request.FullPath, StringComparison.Ordinal))
{
refusal = $"{request.Name} is already there.";
return false;
}
if (request.IsDirectory
&& destination.StartsWith(request.FullPath + "/", StringComparison.Ordinal))
{
refusal = "A directory cannot be moved inside itself.";
return false;
}
refusal = string.Empty;
return true;
}
/// <inheritdoc />
public async ValueTask DisposeAsync()
@@ -1713,13 +2101,31 @@ internal sealed partial class TransfersViewModel : ObservableObject, IAsyncDispo
return RunAsync($"Reading {path}…", () => ListRemoteAsync(path, cancellationToken));
}
/// <remarks>
/// <para>
/// <b>The selection survives if the row it was on does.</b> Every listing replaces every row object, so
/// keeping the object would keep a selection pointing at something no longer in the list; it is re-found
/// by path instead. This matters because a listing is no longer only something somebody asked for — a
/// finished upload refreshes this pane on its own, and a refresh that cleared the selection would take
/// the row out from under whoever was about to press RENAME on it.
/// </para>
/// <para>
/// The path box is written back here rather than by each caller, so that every way of moving — a crumb,
/// UP, a pin, connecting, a rename that lands — leaves the box saying where the pane actually is.
/// </para>
/// </remarks>
private async Task ListRemoteAsync(string path, CancellationToken cancellationToken)
{
var entries = await RequireSession().ListAsync(path, cancellationToken).ConfigureAwait(true);
var wasSelected = SelectedRemoteEntry?.FullPath;
RemotePath = path;
RemotePathDraft = path;
SelectedRemoteEntry = null;
// Whatever made it stale, this is a fresh read of the very directory that was stale.
remoteListingIsStale = false;
RemoteEntries.Clear();
foreach (var entry in entries)
@@ -1734,10 +2140,99 @@ internal sealed partial class TransfersViewModel : ObservableObject, IAsyncDispo
RemoteTrail.Add(new CrumbViewModel(name, crumb));
}
SelectedRemoteEntry = wasSelected is null
? null
: RemoteEntries.FirstOrDefault(
row => string.Equals(row.FullPath, wasSelected, StringComparison.Ordinal));
Status = string.Empty;
}
/// <summary>
/// Re-reads the remote directory because something landed in it, if now is a moment to.
/// </summary>
/// <remarks>
/// <para>
/// <b>An upload that finished is a listing that is wrong.</b> The pane went on showing the directory as
/// it was before the file arrived, and the only way to see the file that had just been sent was to press
/// REFRESH — which is the application asking somebody to tell it about something it did itself.
/// </para>
/// <para>
/// <b>It waits rather than interrupting.</b> Three states are not the moment: another operation is
/// running, which would have two listings racing for the same collection; one of the three questions is
/// on screen, and pulling the listing out from under a question about a row is how the row somebody
/// answered about stops being the row that was acted on; or nothing is connected. In all three the
/// staleness is remembered and settled later — at the end of the operation, or when the question is
/// dismissed.
/// </para>
/// <para>
/// <b>It says nothing.</b> Nobody asked for this listing, so it neither announces itself nor reports a
/// failure: the status line at that moment is carrying the word about the transfer that just finished,
/// which is the news. A refresh that failed leaves the pane as it was and the staleness set, so the next
/// settling tries again.
/// </para>
/// </remarks>
internal async Task SettleRemoteListingAsync()
{
if (!remoteListingIsStale || !IsConnected || IsBusy || IsAskingAboutRemoteEntry
|| RemotePath.Length == 0)
{
return;
}
var said = Status;
IsBusy = true;
try
{
await ListRemoteAsync(RemotePath, CancellationToken.None).ConfigureAwait(true);
Status = said;
}
catch (Exception exception) when (exception is not OutOfMemoryException)
{
remoteListingIsStale = true;
}
finally
{
IsBusy = false;
}
}
/// <summary>
/// Notices that a finished transfer changed a directory that is on screen.
/// </summary>
/// <remarks>
/// Both panes, because both go stale the same way and for the same reason — an upload lands on the host
/// and a download lands on this machine, and whichever pane is showing that directory is now showing it
/// as it was a moment ago. Only the directory actually on screen: a transfer into somewhere else changed
/// nothing anybody is looking at, and re-listing for it would be a round trip per completed transfer in
/// a queue that may be moving a hundred files elsewhere.
/// </remarks>
internal void NoteTransferLanded(TransferSnapshot transfer)
{
if (transfer.Direction is TransferDirection.Upload)
{
if (string.Equals(SftpPath.Parent(transfer.RemotePath), RemotePath, StringComparison.Ordinal))
{
remoteListingIsStale = true;
_ = SettleRemoteListingAsync();
}
return;
}
// The local pane is a filesystem call rather than a round trip, so there is nothing to defer: it is
// re-read where it stands. Compared case-insensitively because this end is Windows as often as not.
if (string.Equals(
Path.GetDirectoryName(transfer.LocalPath), LocalPath, StringComparison.OrdinalIgnoreCase))
{
NavigateLocal(LocalPath);
}
}
/// <remarks>
/// Synchronous, unlike its remote counterpart. A local directory listing is a filesystem call rather than
/// a network round trip, and wrapping it in a task would put a state machine and a thread hop behind
@@ -1748,6 +2243,7 @@ internal sealed partial class TransfersViewModel : ObservableObject, IAsyncDispo
try
{
var entries = LocalDirectory.List(path);
var wasSelected = SelectedLocalEntry?.FullPath;
LocalPath = Path.GetFullPath(path);
SelectedLocalEntry = null;
@@ -1761,6 +2257,13 @@ internal sealed partial class TransfersViewModel : ObservableObject, IAsyncDispo
RebuildLocalTrail();
// Re-found by path rather than kept, for the reason ListRemoteAsync gives: a finished download
// re-reads this pane on its own, and a refresh that cleared the selection would take the row
// out from under whoever was about to send it somewhere.
SelectedLocalEntry = wasSelected is null
? null
: LocalEntries.FirstOrDefault(
row => string.Equals(row.FullPath, wasSelected, StringComparison.OrdinalIgnoreCase));
}
catch (Exception exception) when (exception is IOException or UnauthorizedAccessException)
{
@@ -1877,10 +2380,19 @@ internal sealed partial class TransfersViewModel : ObservableObject, IAsyncDispo
ConnectedPinnedPaths.Clear();
OnPropertyChanged(nameof(HasConnectedPins));
RemotePath = string.Empty;
RemotePathDraft = string.Empty;
RemoteEntries.Clear();
RemoteTrail.Clear();
SelectedRemoteEntry = null;
// Both questions go with the session they were about, and the box either of them was filled in
// from with them. A form left open over a pane that is no longer connected to anything would
// commit against RequireSession's own refusal.
PendingRemoteDeletion = null;
PendingRemoteMove = null;
RemoteMoveTarget = string.Empty;
remoteListingIsStale = false;
// Same ordering reason as the raise at the end of MarkHostConnected: both properties this reads are
// already null above, so the raise belongs after them rather than in OnIsConnectedChanged. This also
// covers OpenBucketAsync, which calls this method first and never itself turns HasLiveFileSession on.
@@ -1911,6 +2423,9 @@ internal sealed partial class TransfersViewModel : ObservableObject, IAsyncDispo
{
ReleaseStaged(e.Transfer.LocalPath);
}
// Whichever pane the bytes landed in is showing that directory as it was before they did.
NoteTransferLanded(e.Transfer);
}
if (Transfers.FirstOrDefault(row => row.Id == e.Transfer.Id) is { } existing)
@@ -1961,6 +2476,10 @@ internal sealed partial class TransfersViewModel : ObservableObject, IAsyncDispo
{
IsBusy = false;
}
// The one place every command on this screen passes through on its way out, which makes it the one
// place a listing that went stale while it was running can safely be settled.
await SettleRemoteListingAsync().ConfigureAwait(true);
}
partial void OnSelectedHostChanged(HostRowViewModel? value) =>
@@ -2002,7 +2521,7 @@ internal sealed partial class TransfersViewModel : ObservableObject, IAsyncDispo
{
OnPropertyChanged(nameof(CanDownload));
OnPropertyChanged(nameof(CanUpload));
OnPropertyChanged(nameof(CanDeleteRemote));
RaiseItemActionState();
// Both ways, and the disconnecting half is the one worth stating: closing a session puts the pane
// back to its invitation rather than to the form, so what the pane shows after a disconnect is the
@@ -2019,14 +2538,37 @@ internal sealed partial class TransfersViewModel : ObservableObject, IAsyncDispo
partial void OnSelectedRemoteEntryChanged(RemoteEntryRowViewModel? value)
{
OnPropertyChanged(nameof(CanDownload));
OnPropertyChanged(nameof(SelectedRemoteName));
PendingRemoteDeletion = null;
PendingRemoteMove = null;
}
partial void OnPendingRemoteDeletionChanged(RemoteDeletionRequest? value)
{
OnPropertyChanged(nameof(IsConfirmingRemoteDeletion));
RaiseItemActionState();
}
partial void OnPendingRemoteMoveChanged(RemoteMoveRequest? value)
{
OnPropertyChanged(nameof(IsMovingRemote));
RaiseItemActionState();
}
/// <summary>Raises the flags the three item buttons and their two forms are drawn from.</summary>
/// <remarks>
/// Together, because they are one fact — is there a question on screen, and is anything connected —
/// read five ways, and a caller that raised some of them would leave a button live beside a form that
/// says it is not.
/// </remarks>
private void RaiseItemActionState()
{
OnPropertyChanged(nameof(IsAskingAboutRemoteEntry));
OnPropertyChanged(nameof(ShowsRemoteItemActions));
OnPropertyChanged(nameof(CanDeleteRemote));
OnPropertyChanged(nameof(CanRenameRemote));
OnPropertyChanged(nameof(CanMoveRemote));
}
partial void OnSelectedLocalEntryChanged(LocalEntryRowViewModel? value) =>
+170 -7
View File
@@ -16,7 +16,8 @@
happened to straddle a frame boundary, which shows up as occasional mojibake in exactly the
conditions that are hardest to reproduce.
3. The socket reconnects itself, forever, with backoff. This page's WebView is routinely killed
3. The socket reconnects itself, forever, with backoff — and on being looked at again, which is not
the same thing and is the half a timer cannot cover. This page's WebView is routinely killed
and reloaded by Android under memory pressure or simply for being backgrounded, so "the
socket closed" is an ordinary event here, not the end of the terminal's life — see connect().
A reloaded page starts with an empty session map, so createSession is idempotent (a session
@@ -52,6 +53,22 @@ const SCROLLBACK_LINES = 5000;
const RECONNECT_INITIAL_DELAY_MS = 1000;
const RECONNECT_MAX_DELAY_MS = 5000;
/*
How long a socket is given to finish its handshake before it is treated as a failure.
A socket that cannot connect normally says so and says it quickly — 'error' then 'close', within a
millisecond or two of a loopback refusal. The case this covers is the one that says nothing: an attempt
parked in CONNECTING with no event ever coming, which is what a WebSocket opened by a renderer that is
then suspended, or one whose handshake the host never answers, leaves this page holding.
Without the watchdog that state is terminal, and quietly so. Every retry in this file is scheduled by a
close or an error, so an attempt that produces neither schedules nothing: the banner says the view is
reconnecting for the rest of the page's life while nothing whatever is reconnecting. Five seconds is
generous against a handshake that ordinarily takes about a millisecond, and short against somebody
waiting on their terminal to come back.
*/
const HANDSHAKE_TIMEOUT_MS = 5000;
/*
Styled like the SESSION_CLOSED banner (matching \x1b[38;5;244, the same dim grey), but written by
createSession's caller rather than by createSession itself: only a *replay* landing on a pane that
@@ -583,8 +600,47 @@ function handleFrame(buffer) {
}
}
/*
── THE SOCKET COMES BACK BY ITSELF, INCLUDING FOR A PAGE NOBODY HAS LOOKED AT IN AN HOUR ────────────
Retrying on a timer is the easy half and was the whole of this. The three rules below are what make the
retry actually reach a page that has been sitting collapsed — each of them a way this page was found
showing "Reconnecting the terminal view…" over a socket that nothing was reconnecting.
1. ONLY THE CURRENT ATTEMPT'S EVENTS COUNT. connect() abandons whatever socket was attached before it,
and an abandoned socket still reports its end: the host aborts it the moment the newcomer upgrades,
which is TerminalDataPlane.UpgradeAsync's takeover doing exactly what it is meant to. Counting that
close as a fresh failure schedules a retry against a socket that has just succeeded, and the
takeover then aborts *that* one, whose close schedules the next — a loop with no fixed point, in
which the terminal reconnects every second or so forever and the banner is up for most of it. Every
handler below asks whether it is still the page's socket before it does anything.
2. AN ATTEMPT THAT NEVER FINISHES IS A FAILURE TOO. See HANDSHAKE_TIMEOUT_MS.
3. COMING BACK IS A REASON TO TRY, NOT ONLY THE CLOCK. The retry is a setTimeout chain, and a chain is
precisely what a WebView is entitled to stop running. Chromium throttles timers in a page nobody is
looking at — down to once a minute once it has been hidden five minutes — and a renderer that is
frozen, or reclaimed and not yet reloaded, runs none of them at all. So the socket drops while nobody
is watching, the banner goes up, the retry is scheduled, and the retry is then the one thing not
running: coming back shows a terminal that says it is reconnecting and, for as long as that lasts,
is not.
The phone is where this is easiest to reach, because leaving the terminal for another screen
collapses its WebView to GONE — see createSession's note on the GPU context — and a WebView with no
surface is a page the platform may treat as hidden. Which of the two mechanisms actually bit is not
established here, and does not need to be: both end with a timer that will not run, and the fix is
not to guess at either but to stop depending on the timer alone.
Hence the wake-ups at the bottom of this file. What they add is not a faster retry; it is a retry
driven by the one thing that cannot be throttled, which is the user arriving.
*/
/** @type {number | null} */
let reconnectTimer = null;
/** @type {number | null} */
let handshakeTimer = null;
let reconnectDelay = RECONNECT_INITIAL_DELAY_MS;
/**
@@ -608,16 +664,86 @@ function scheduleReconnect() {
reconnectDelay = Math.min(reconnectDelay * 2, RECONNECT_MAX_DELAY_MS);
}
/**
* Tries the socket again now, if it is down.
*
* The entry point for "somebody is looking at this page again", and it has to be safe to call as often
* as that happens — which on the desktop is every time the window is clicked. A socket that is up makes
* this nothing at all.
*
* An attempt still in CONNECTING is left alone rather than restarted: it may be about to succeed, and
* the one that is not is already the handshake watchdog's to give up on.
*/
function reconnectIfDown() {
if (socket !== null
&& (socket.readyState === WebSocket.OPEN || socket.readyState === WebSocket.CONNECTING)) {
return;
}
// Whatever the timer was going to do, this is doing now. Left pending it would land on top of the
// socket this call is about to open, and the takeover that followed is the loop rule 1 describes.
if (reconnectTimer !== null) {
clearTimeout(reconnectTimer);
reconnectTimer = null;
}
// Back to the quick attempt. The wait grew to space out retries during an outage nobody was watching,
// and being called at all means somebody is watching now.
reconnectDelay = RECONNECT_INITIAL_DELAY_MS;
connect();
}
function connect() {
const token = root.dataset.token;
const url = root.dataset.socket;
/*
Whatever was attached is abandoned here, and closed rather than dropped: the host takes the socket
over regardless, but one left open is a connection it has to abort and an event this page then has to
ignore. Cleared out of `socket` before the close, so that every handler — including that close,
whenever it lands — can already tell the attempt is no longer the page's.
*/
const abandoned = socket;
socket = null;
abandoned?.close();
// The token travels as a subprotocol rather than a query parameter, which keeps it out of
// anything that logs URLs.
socket = new WebSocket(url, ['dodossh.terminal.v1', `token.${token}`]);
socket.binaryType = 'arraybuffer';
const pending = new WebSocket(url, ['dodossh.terminal.v1', `token.${token}`]);
pending.binaryType = 'arraybuffer';
socket = pending;
socket.addEventListener('open', () => {
/** Whether this attempt is still the page's, rather than one a later connect() has replaced. */
const isCurrent = () => socket === pending;
const forgetHandshakeTimer = () => {
if (handshakeTimer !== null) {
clearTimeout(handshakeTimer);
handshakeTimer = null;
}
};
forgetHandshakeTimer();
handshakeTimer = setTimeout(() => {
handshakeTimer = null;
// Still CONNECTING with nothing on its way. Only the retry is arranged here; abandoning the attempt
// is left to the connect() that retry runs, which is the one place a socket is replaced.
if (isCurrent() && pending.readyState === WebSocket.CONNECTING) {
scheduleReconnect();
}
}, HANDSHAKE_TIMEOUT_MS);
pending.addEventListener('open', () => {
// A replaced attempt cannot reach here — connect() closes what it abandons, and a socket closed
// while connecting never opens — so this is a guard against the ordering rather than a live case.
if (!isCurrent()) {
return;
}
forgetHandshakeTimer();
setTransportStatus('');
// Back to the quick attempt for whatever the next failure turns out to be. Kept slow between
@@ -625,14 +751,25 @@ function connect() {
reconnectDelay = RECONNECT_INITIAL_DELAY_MS;
});
socket.addEventListener('message', (event) => handleFrame(event.data));
pending.addEventListener('message', (event) => {
if (isCurrent()) {
handleFrame(event.data);
}
});
// Both close and error retry. They are not the same event on every failure — a socket that never
// opens can fire only 'error', one that opens and later drops fires only 'close' — and the host
// side of this same problem (TerminalDataPlane.UpgradeAsync's takeover) is exactly why retrying is
// safe: whichever attempt eventually reaches the host, a fresh valid upgrade always wins the socket.
socket.addEventListener('close', scheduleReconnect);
socket.addEventListener('error', scheduleReconnect);
const retry = () => {
if (isCurrent()) {
forgetHandshakeTimer();
scheduleReconnect();
}
};
pending.addEventListener('close', retry);
pending.addEventListener('error', retry);
}
// One observer for the whole root rather than one per pane: resizes arrive in bursts while a
@@ -645,4 +782,30 @@ new ResizeObserver(() => {
window.addEventListener('beforeunload', () => socket?.close());
/*
The ways this page finds out somebody is looking at it again — rule 3 at the top of the transport
section. All three end in the same check, and that check is what makes them safe to be as noisy as they
are: with a healthy socket every one of them does nothing.
'visibilitychange' is the phone's. A WebView collapsed to GONE is a hidden page, so coming back to the
terminal screen is the event that says so, and it is the same event Chromium lifts its own throttling
on — this page simply does not wait to be asked twice.
'focus' is the desktop's, where the page is *not* marked hidden while the WebView is collapsed
(measured; see docs/platform-flags.md) but a window left in the background for hours has had its timers
throttled all the same. It fires when the terminal takes the keyboard back, which is the same gesture.
'online' is neither head's ordinary case, because the socket is loopback and has nothing to do with the
network — but the event does follow a machine coming back from sleep, and a page with a dead socket has
no reason to ignore any hint that the world has moved.
*/
document.addEventListener('visibilitychange', () => {
if (!document.hidden) {
reconnectIfDown();
}
});
window.addEventListener('focus', reconnectIfDown);
window.addEventListener('online', reconnectIfDown);
connect();
+87
View File
@@ -234,6 +234,93 @@ public static class SftpPath
return trail;
}
/// <summary>
/// Turns something a person typed into an absolute path.
/// </summary>
/// <remarks>
/// <para>
/// The file browser's path box is the reason this exists. A breadcrumb can only offer the path it is
/// already standing on, so reaching <c>/var/log/nginx</c> from a home directory is a click and a round
/// trip per level — and somebody who already knows where they are going types it instead. What they
/// type is not always absolute: <c>..</c>, <c>logs</c> and <c>~/.ssh</c> are all ordinary answers to
/// "where to", and a box that took only a leading slash would refuse three of the four shapes every
/// shell accepts.
/// </para>
/// <para>
/// <b>Resolved here rather than left to the server.</b> An SFTP server does resolve a relative path —
/// against the session's own working directory, which is not necessarily the directory this pane is
/// showing — so handing one over would navigate somewhere the breadcrumb above it did not predict. What
/// this returns is absolute, which is the only kind every other member here takes.
/// </para>
/// <para>
/// <c>..</c> is collapsed textually, which is one thing a shell's own <c>cd</c> does not do: through a
/// symbolic link, <c>..</c> leads to the link's parent here and to the target's parent on the server.
/// The difference shows only on a path that walks into a link and back out of it, and the alternative is
/// a <c>realpath</c> round trip before anything is listed at all.
/// </para>
/// </remarks>
/// <param name="current">The directory a relative path is taken to be relative to.</param>
/// <param name="typed">What was typed. Blank answers <paramref name="current"/>.</param>
/// <param name="home">
/// What <c>~</c> means, or null in a session that has not said. A leading <c>~</c> with no home to
/// expand stays an ordinary segment rather than being guessed at — a directory really can be called
/// that, and inventing a home directory to point at would be worse than listing the one that is there.
/// </param>
public static string Resolve(string current, string typed, string? home = null)
{
ArgumentException.ThrowIfNullOrEmpty(current);
ArgumentNullException.ThrowIfNull(typed);
var wanted = typed.Trim();
if (wanted.Length == 0)
{
return Normalize(current);
}
if (home is { Length: > 0 }
&& (string.Equals(wanted, "~", StringComparison.Ordinal)
|| wanted.StartsWith("~/", StringComparison.Ordinal)))
{
wanted = wanted.Length == 1 ? home : Combine(home, wanted[2..]);
}
return Normalize(IsAbsolute(wanted) ? wanted : Combine(current, wanted));
}
/// <summary>Collapses <c>.</c>, <c>..</c> and repeated separators, anchored at the root.</summary>
/// <remarks>
/// <c>..</c> above the root is the root, as it is in every shell: <c>/../..</c> is <c>/</c> rather than
/// a failure, because there is nowhere else for it to be.
/// </remarks>
private static string Normalize(string path)
{
var walked = new List<string>();
foreach (var segment in path.Split('/', StringSplitOptions.RemoveEmptyEntries))
{
switch (segment)
{
case ".":
break;
case "..":
if (walked.Count > 0)
{
walked.RemoveAt(walked.Count - 1);
}
break;
default:
walked.Add(segment);
break;
}
}
return walked.Count == 0 ? Root : Root + string.Join('/', walked);
}
}
/// <summary>
@@ -236,6 +236,51 @@ public sealed class QuickConnectTests : IAsyncLifetime
});
}
/// <remarks>
/// The palette searches every vault the session holds a key for, so a row has to say which one it came
/// out of. Two machines a team and a person both call <c>prod-db</c> are otherwise two identical rows,
/// and Enter takes whichever the ranking happened to put first.
/// <para>
/// Typed into rather than read off the unfiltered list, because the shared vault's host sorts last — the
/// active vault's rows come first — and the list virtualises, so the row this is about might never be
/// realised. Narrowing to it also proves the search reaches past the active vault at all.
/// </para>
/// </remarks>
[Fact]
public async Task AResultSaysWhichVaultItCameOutOf()
{
await SeedSharedHostAsync();
await OnThePaletteAsync((palette, window) =>
{
shell.SearchText = "prod-db";
Relayout(window);
var found = shell.SearchResults.ShouldHaveSingleItem();
found.VaultId.ShouldNotBe(session.ActiveVaultId, "the palette reaches past the active vault");
VisibleTexts(RowFor(palette, found)).ShouldContain("PLATFORM SECRETS", StringComparer.Ordinal);
});
}
/// <remarks>
/// The other half of the rule, and the reason the name is a badge rather than a column: a vault named on
/// every row of a session that has only one is the same fact repeated, which is noise rather than a
/// reading. <c>HostRowViewModel.VaultBadge</c> is empty there, and an empty line has to collapse rather
/// than leave a gap above the kind word.
/// </remarks>
[Fact]
public async Task AResultNamesNoVaultWhenThereIsOnlyOneToBeIn()
{
await OnThePaletteAsync((palette, _) =>
{
var first = shell.SearchResults[0];
first.HasVaultBadge.ShouldBeFalse("this fixture's session holds the personal vault alone");
VisibleTexts(RowFor(palette, first)).ShouldNotContain("PERSONAL", StringComparer.Ordinal);
});
}
/// <remarks>
/// The palette is a box somebody is expected to start typing into, and for a while it was not: the window
/// focused it from the view model's <c>PropertyChanged</c>, which runs before the binding that reveals the
@@ -307,6 +352,25 @@ public sealed class QuickConnectTests : IAsyncLifetime
.OfType<ListBoxItem>()
.First(item => ReferenceEquals(item.DataContext, host));
/// <summary>What one row actually draws, in order, ignoring the lines that collapsed.</summary>
private static List<string> VisibleTexts(Visual row) =>
row.GetVisualDescendants()
.OfType<TextBlock>()
.Where(text => text.IsEffectivelyVisible)
.Select(text => text.Text ?? string.Empty)
.ToList();
/// <summary>Runs the layout pass the application's dispatcher would run after the list changed.</summary>
/// <remarks>
/// Without it the new rows are in the collection but not in the visual tree, so <see cref="RowFor"/>
/// finds nothing to look at.
/// </remarks>
private static void Relayout(Window window)
{
Dispatcher.UIThread.RunJobs();
window.UpdateLayout();
}
private static Point Centre(Visual control, Visual window) =>
control.TranslatePoint(new Point(control.Bounds.Width / 2, control.Bounds.Height / 2), window)
?? throw new InvalidOperationException("the control is not in this window's tree");
@@ -325,4 +389,37 @@ public sealed class QuickConnectTests : IAsyncLifetime
await vault.LoadAsync(Token);
}
/// <summary>
/// Adds a second, shared vault to the fixture's session and files one host into it.
/// </summary>
/// <remarks>
/// Straight into the session rather than through <c>VaultsViewModel</c>, which is the technique the
/// settings pages' suite uses and for the same reason: creating a vault needs a connection, and this
/// shell has none. The key is generated on this machine either way, so what the session ends up holding
/// is the same thing a real creation leaves behind — see <see cref="StubTeamServer"/>.
/// </remarks>
private async Task SeedSharedHostAsync()
{
using var teamServer = new StubTeamServer();
var shared = await session.CreateTeamVaultAsync(
teamServer.Teams, StubTeamServer.SharedTeamId, "Platform secrets", Token);
await vault.LoadAsync(Token);
vault.SelectedTargetVault =
vault.TargetVaults.Single(choice => choice.VaultId == shared.VaultId);
vault.NewHostCommand.Execute(null);
vault.EditorLabel = "prod-db";
vault.EditorHostname = "db.internal";
vault.EditorUsername = "deploy";
await vault.SaveHostCommand.ExecuteAsync(null);
vault.IsEditing.ShouldBeFalse(vault.Status);
await vault.LoadAsync(Token);
}
}
@@ -1,5 +1,6 @@
using Avalonia;
using Avalonia.Controls;
using Avalonia.Controls.Primitives;
using Avalonia.Headless;
using Avalonia.Input;
using Avalonia.Threading;
@@ -1311,10 +1312,18 @@ public sealed class ScreenLayoutTests : IAsyncLifetime
/// The question in front of deleting something on the host, which takes a row out of the remote pane's
/// column while the listing under it is still showing. A directory, because that is the longer of the
/// two warnings, and a path deep enough to wrap in a pane a third of the window wide.
/// <para>
/// Connected, because that is the only state this question can be asked in — and it is the state that
/// asks it at the narrowest budget, since <c>IsConnected</c> is what pulls QUICK ACCESS's own sidebar
/// in beside this screen and takes the pane down to 204 pixels. Measured disconnected until the row of
/// item actions arrived beside DELETE, which is a shape this card has to share the pane's height with.
/// </para>
/// </remarks>
[Fact]
public async Task TheTransfersScreenFitsWithADeletionInQuestion()
{
transfers.IsConnected = true;
transfers.RemotePath = "/srv/releases/site/backups/nightly";
transfers.PendingRemoteDeletion = new RemoteDeletionRequest(
"2026-07-30",
"/srv/releases/site/backups/nightly/2026-07-30",
@@ -1323,6 +1332,112 @@ public sealed class ScreenLayoutTests : IAsyncLifetime
await MeasureTransfersAsync(faults => faults.ShouldBeEmpty());
}
/// <remarks>
/// The rename form, which takes a row out of the remote pane's column the way the deletion question
/// does but is a taller shape: a heading, the path, a label, a box and a sentence, over a listing that
/// is still showing. Measured connected, so it is asked at the 204-pixel width the session shell's own
/// sidebar leaves this pane.
/// </remarks>
[Fact]
public async Task TheTransfersScreenFitsWithARenameInQuestion()
{
transfers.IsConnected = true;
transfers.RemotePath = "/srv/releases/site/shared";
transfers.PendingRemoteMove = new RemoteMoveRequest(
"site-backup-2026-07-30.sql.gz",
"/srv/releases/site/shared/site-backup-2026-07-30.sql.gz",
IsDirectory: false,
RemoteMoveKind.Rename);
transfers.RemoteMoveTarget = "site-backup-2026-07-30.sql.gz";
await MeasureTransfersAsync(faults => faults.ShouldBeEmpty("with a rename being filled in"));
}
/// <remarks>
/// The move form is the same shape with longer words in it — see <c>RemoteMoveRequest.Note</c>, whose
/// move half is two sentences where the rename half is one — and a directory, which is the kind whose
/// destination is most likely to be a deep path typed in full.
/// </remarks>
[Fact]
public async Task TheTransfersScreenFitsWithAMoveInQuestion()
{
transfers.IsConnected = true;
transfers.RemotePath = "/srv/releases/site/shared";
transfers.PendingRemoteMove = new RemoteMoveRequest(
"uploads",
"/srv/releases/site/shared/uploads",
IsDirectory: true,
RemoteMoveKind.Move);
transfers.RemoteMoveTarget = "/srv/releases/site/shared/archive/2026/production";
await MeasureTransfersAsync(faults => faults.ShouldBeEmpty("with a move being filled in"));
}
/// <remarks>
/// <para>
/// The pane header's path is a box that can be typed into, and this is what says so: the regression it
/// guards against is the one this replaced, a <c>TextBlock</c> that printed where the pane was and gave
/// no way to say where to go. It is bound to <see cref="TransfersViewModel.RemotePathDraft"/> rather
/// than to <c>RemotePath</c>, which is the difference between a box somebody can finish typing into and
/// one that navigates on every keystroke.
/// </para>
/// <para>
/// The three item buttons are asserted in the same pass because they and the box are the same change:
/// DELETE left the header to join RENAME and MOVE below it, and the room the box has is exactly the
/// room those two buttons no longer take up there.
/// </para>
/// </remarks>
[Fact]
public async Task TheRemotePanesPathIsTypedAndItsRowActionsAreAllThere()
{
transfers.IsConnected = true;
transfers.RemotePath = "/srv/releases/site/shared/uploads/production/2026/08/nightly";
transfers.RemotePathDraft = transfers.RemotePath;
transfers.RemoteEntries.Add(new RemoteEntryRowViewModel(new SftpEntry(
"docker-compose.yml", "/srv/releases/site/docker-compose.yml", SftpEntryKind.File,
3_400, TimeProvider.System.GetUtcNow(), "-rw-r--r--")));
transfers.SelectedRemoteEntry = transfers.RemoteEntries[0];
await LayoutHarness.OnTheUiThreadAsync(
() =>
{
var screen = new TransfersScreen { DataContext = transfers };
var window = LayoutHarness.HostAtMinimumSize(
screen, LayoutHarness.SessionScreenWidth(sidebarVisible: true), LayoutHarness.SessionScreenHeight);
try
{
var box = screen.GetVisualDescendants()
.OfType<TextBox>()
.Single(text => text.Classes.Contains("pathbox"));
box.Text.ShouldBe(transfers.RemotePath);
box.IsEffectivelyEnabled.ShouldBeTrue("nothing may type into a disconnected pane");
box.IsReadOnly.ShouldBeFalse();
var tips = screen.GetVisualDescendants()
.OfType<Button>()
.Select(button => ToolTip.GetTip(button) as string)
.Where(tip => tip is not null)
.ToList();
tips.ShouldContain("Rename on the host");
tips.ShouldContain("Move to another directory");
tips.ShouldContain("Delete on the host");
LayoutHarness.Unreachable(window).ShouldBeEmpty("with a row chosen and its actions showing");
}
finally
{
window.Close();
}
},
Token);
}
// ---- ◆ wave C: the restyled panes and the TRANSFERS strip ----
/// <remarks>
@@ -2057,6 +2172,262 @@ public sealed class ScreenLayoutTests : IAsyncLifetime
/// runtime — see <see cref="LayoutHarness.SessionScreenWidth"/> — so a test that connects before calling
/// this measures the tighter, sidebar-narrowed shape without having to say so twice.
/// </remarks>
// ---- ◆ The listings' columns ----
/// <remarks>
/// <para>
/// <b>Every cell shows what it holds, at a width this screen actually gets.</b> The columns were fixed
/// pixel widths until they were measured against their own content: MODIFIED prints a sixteen-character
/// timestamp needing 116 pixels and had 52, so it was truncated at every width the application has ever
/// been drawn at — on a maximised window it read "2026-08" beside a NAME column with four hundred empty
/// pixels in it. PERMS and SIZE were short by the same kind of margin.
/// </para>
/// <para>
/// Asserted by measuring each cell's own text unconstrained and holding the rendered width against it,
/// rather than against numbers written down here: a column that fits is a column at least as wide as
/// what it has to draw, and any other formulation is this test agreeing with the markup about an
/// arithmetic they both got from the same place.
/// </para>
/// </remarks>
[Fact]
public async Task TheListingColumnsShowTheirContentInFullWhenThereIsRoom()
{
SeedBothListings();
await LayoutHarness.OnTheUiThreadAsync(
() =>
{
var screen = new TransfersScreen { DataContext = transfers };
var window = LayoutHarness.HostAtMinimumSize(
screen, MaximisedSessionScreenWidth, LayoutHarness.SessionScreenHeight);
try
{
foreach (var text in new[] { "2.1 KB", "2026-08-21 11:36", "-rw-r--r--", "2026-07-04 09:00" })
{
var cell = screen.GetVisualDescendants()
.OfType<TextBlock>()
.First(block => string.Equals(block.Text, text, StringComparison.Ordinal));
cell.Bounds.Width.ShouldBeGreaterThanOrEqualTo(
Unconstrained(cell) - 0.5, $"'{text}' has to fit the column it is drawn in");
}
}
finally
{
window.Close();
}
},
Token);
}
/// <remarks>
/// The headings are right-aligned in their own columns, so two of them whose columns are exactly the
/// width of their text run together: SIZE ended on the pixel MODIFIED began at, and the row read
/// "SIZEMODIFIED". This holds the gap that fixes it — a left margin on each of the three, which does not
/// move a right-aligned label but does stop the column before it reaching this one.
/// </remarks>
[Fact]
public async Task TheListingHeadingsDoNotRunIntoEachOther()
{
SeedBothListings();
await LayoutHarness.OnTheUiThreadAsync(
() =>
{
var screen = new TransfersScreen { DataContext = transfers };
var window = LayoutHarness.HostAtMinimumSize(
screen, MaximisedSessionScreenWidth, LayoutHarness.SessionScreenHeight);
try
{
// Per pane, not across both. Each has its own NAME at its own left edge, and a list of
// all seven sorted by position pairs the local pane's last heading with the remote
// pane's first — two labels in different panes, which no amount of margin separates.
var rows = screen.GetVisualDescendants()
.OfType<Grid>()
.Where(grid => grid.Children.OfType<TextBlock>().Any(
block => block.Classes.Contains("label")
&& string.Equals(block.Text, "NAME", StringComparison.Ordinal)))
.ToList();
rows.Count.ShouldBe(2, "one heading row per pane");
foreach (var row in rows)
{
var headings = row.Children
.OfType<TextBlock>()
.Where(block => block.Classes.Contains("label"))
.Select(block => (block.Text, Left: block.Bounds.X, Right: block.Bounds.Right))
.OrderBy(heading => heading.Left)
.ToList();
foreach (var (before, after) in headings.Zip(headings.Skip(1)))
{
after.Left.ShouldBeGreaterThan(
before.Right, $"'{before.Text}' must not touch '{after.Text}'");
}
}
}
finally
{
window.Close();
}
},
Token);
}
/// <remarks>
/// <para>
/// The other end of the same fault. At the 204 pixels the session shell's own sidebar leaves a pane, the
/// fixed columns took 176 of a row's 180 and the remote pane's NAME cell measured <b>zero</b> — a file
/// browser drawing sizes, timestamps and modes for rows whose names were not on screen at all.
/// </para>
/// <para>
/// No column carries a MinWidth, which is what keeps this from being a fight the row can lose: at any
/// width all four give ground together, and NAME — weighted heaviest — is the last to run out. What is
/// asserted is only that it has not run out, because how much of a name fits in 204 pixels is a question
/// with no good answer.
/// </para>
/// </remarks>
[Fact]
public async Task TheNameColumnSurvivesTheNarrowestBudget()
{
SeedBothListings();
await LayoutHarness.OnTheUiThreadAsync(
() =>
{
var screen = new TransfersScreen { DataContext = transfers };
var window = LayoutHarness.HostAtMinimumSize(
screen, LayoutHarness.SessionScreenWidth(sidebarVisible: true), LayoutHarness.SessionScreenHeight);
try
{
foreach (var name in new[] { ".bash_history", ".azure-devops" })
{
var cell = screen.GetVisualDescendants()
.OfType<TextBlock>()
.First(block => string.Equals(block.Text, name, StringComparison.Ordinal));
cell.Bounds.Width.ShouldBeGreaterThan(20, $"'{name}' must be readable at all");
}
}
finally
{
window.Close();
}
},
Token);
}
/// <remarks>
/// A placeholder cut off mid-word reads as a rendering fault rather than as a hint — MKDIR's box drew
/// "new directo" and the pane header's drew a path ending mid-segment. Both are boxes whose width is
/// fixed by the pane's own narrowest budget, so the text is what had to give.
/// </remarks>
[Fact]
public async Task ThePaneBoxesPlaceholdersFitTheBoxesTheyAreIn()
{
transfers.IsConnected = true;
await LayoutHarness.OnTheUiThreadAsync(
() =>
{
var screen = new TransfersScreen { DataContext = transfers };
var window = LayoutHarness.HostAtMinimumSize(
screen, LayoutHarness.SessionScreenWidth(sidebarVisible: true), LayoutHarness.SessionScreenHeight);
try
{
foreach (var box in screen.GetVisualDescendants().OfType<TextBox>())
{
// The picker's own password box is in the collapsed half of the invitation, so it
// lays out at zero width and has no room for anything. Only what is on screen.
if (box.Watermark is not { Length: > 0 } mark || !box.IsEffectivelyVisible)
{
continue;
}
var room = box.Bounds.Width - box.Padding.Left - box.Padding.Right;
room.ShouldBeGreaterThanOrEqualTo(
Measured(mark, box.FontSize, box.FontFamily),
$"the placeholder '{mark}' has to fit its own box");
}
}
finally
{
window.Close();
}
},
Token);
}
/// <summary>Puts one row of each pane's own shape in, with content of a real length.</summary>
/// <remarks>
/// The local pane is cleared first for the reason <see cref="TheRowTemplateShowsSizeAndDateColumns"/>
/// gives: it lists this fixture's real home directory, and a virtualizing ListBox realises only the rows
/// that fit — a row appended after those would never be built, and the assertion would find nothing to
/// have missed.
/// </remarks>
private void SeedBothListings()
{
transfers.IsConnected = true;
transfers.RemotePath = "/root";
transfers.RemoteEntries.Add(new RemoteEntryRowViewModel(new SftpEntry(
".bash_history",
"/root/.bash_history",
SftpEntryKind.File,
2_150,
new DateTimeOffset(2026, 8, 21, 11, 36, 0, TimeSpan.Zero),
"-rw-r--r--")));
transfers.LocalEntries.Clear();
transfers.LocalEntries.Add(new LocalEntryRowViewModel(new LocalEntry(
".azure-devops",
Path.Combine(Path.GetTempPath(), ".azure-devops"),
IsDirectory: true,
Length: 0,
new DateTimeOffset(2026, 7, 4, 9, 0, 0, TimeSpan.Zero))));
}
/// <summary>
/// What a session-shell screen gets on a maximised window, which is where the columns were reported
/// wrong.
/// </summary>
/// <remarks>
/// A 1843-pixel window less the shell's own 26-pixel padding a side, its 1-pixel border a side, and
/// QUICK ACCESS's 300 — the arithmetic <see cref="LayoutHarness.SessionScreenWidth"/> does, at a width
/// that constant cannot express because it is pinned to the window's <em>minimum</em>. Both belong in
/// this file: the minimum is what everything else here measures against, and this is the width at which
/// the numeric columns reach their caps and the question "does the content fit" has a yes to give.
/// Below it they share the width instead, which is what
/// <see cref="TheNameColumnSurvivesTheNarrowestBudget"/> holds the other end of.
/// </remarks>
private const double MaximisedSessionScreenWidth = 1843 - (2 * 26) - (2 * 1) - 300;
/// <summary>What a rendered block would want if nothing bounded it.</summary>
private static double Unconstrained(TextBlock block) =>
Measured(block.Text ?? string.Empty, block.FontSize, block.FontFamily);
/// <inheritdoc cref="Unconstrained" />
private static double Measured(string text, double fontSize, Avalonia.Media.FontFamily family)
{
var block = new TextBlock { Text = text, FontSize = fontSize, FontFamily = family };
block.Measure(new Size(double.PositiveInfinity, double.PositiveInfinity));
return block.DesiredSize.Width;
}
private Task MeasureTransfersAsync(Action<IReadOnlyList<string>> assert) =>
LayoutHarness.OnTheUiThreadAsync(
() =>
+49 -8
View File
@@ -68,6 +68,15 @@ internal sealed class FakeSshConnectionFactory : ISshConnectionFactory, ISftpSes
return new FakeSshConnection(request);
}
/// <summary>The file-transfer session this factory last handed out, or null when it never has.</summary>
/// <remarks>
/// Kept so a test can read back what the screen actually asked the host to do — which path was renamed,
/// which was deleted, which directories were listed. The screen reports all three in its own status
/// line, and a suite that asserted only on that would be checking a sentence this code wrote about
/// itself rather than the operation it claims to have performed.
/// </remarks>
internal FakeSftpSession? OpenedSftp { get; private set; }
/// <inheritdoc />
public Task<ISftpSession> OpenSftpAsync(
SshConnectionRequest request,
@@ -75,9 +84,14 @@ internal sealed class FakeSshConnectionFactory : ISshConnectionFactory, ISftpSes
{
SftpRequests.Add(request);
return Failure is { } failure
? Task.FromException<ISftpSession>(failure)
: Task.FromResult<ISftpSession>(new FakeSftpSession(request));
if (Failure is { } failure)
{
return Task.FromException<ISftpSession>(failure);
}
OpenedSftp = new FakeSftpSession(request);
return Task.FromResult<ISftpSession>(OpenedSftp);
}
}
@@ -103,9 +117,26 @@ internal sealed class FakeSftpSession(SshConnectionRequest request) : ISftpSessi
/// <inheritdoc />
public string HomeDirectory => $"/home/{request.Username}";
/// <summary>Every directory this session has been asked to list, in order.</summary>
/// <remarks>
/// The evidence that a refresh happened at all. A listing whose contents never change — this one always
/// answers the same single row — leaves no other trace of having been re-read, which is exactly the
/// thing the automatic refresh after a transfer has to be proved to do.
/// </remarks>
internal List<string> Listed { get; } = [];
/// <summary>Every rename this session has been asked for, as it was asked.</summary>
internal List<(string From, string To)> Renamed { get; } = [];
/// <summary>Every path this session has been asked to delete.</summary>
internal List<string> Deleted { get; } = [];
/// <inheritdoc />
public Task<IReadOnlyList<SftpEntry>> ListAsync(string path, CancellationToken cancellationToken) =>
Task.FromResult<IReadOnlyList<SftpEntry>>(
public Task<IReadOnlyList<SftpEntry>> ListAsync(string path, CancellationToken cancellationToken)
{
Listed.Add(path);
return Task.FromResult<IReadOnlyList<SftpEntry>>(
[
new SftpEntry(
"notes.txt",
@@ -115,6 +146,7 @@ internal sealed class FakeSftpSession(SshConnectionRequest request) : ISftpSessi
DateTimeOffset.UnixEpoch,
"-rw-r--r--"),
]);
}
/// <inheritdoc />
public Task<SftpEntry?> StatAsync(string path, CancellationToken cancellationToken) =>
@@ -133,11 +165,20 @@ internal sealed class FakeSftpSession(SshConnectionRequest request) : ISftpSessi
Task.CompletedTask;
/// <inheritdoc />
public Task DeleteAsync(string path, CancellationToken cancellationToken) => Task.CompletedTask;
public Task DeleteAsync(string path, CancellationToken cancellationToken)
{
Deleted.Add(path);
return Task.CompletedTask;
}
/// <inheritdoc />
public Task RenameAsync(string fromPath, string toPath, CancellationToken cancellationToken) =>
Task.CompletedTask;
public Task RenameAsync(string fromPath, string toPath, CancellationToken cancellationToken)
{
Renamed.Add((fromPath, toPath));
return Task.CompletedTask;
}
/// <inheritdoc />
public ValueTask DisposeAsync()
@@ -11,6 +11,7 @@ using DodoSSH.Client.Shell.ViewModels;
using DodoSSH.Client.Ssh;
using DodoSSH.Client.Storage;
using DodoSSH.Client.Sync;
using DodoSSH.Client.Transfer;
using DodoSSH.Client.Terminal;
using DodoSSH.Crypto;
@@ -1765,6 +1766,28 @@ public sealed class ShellFlowTests : IAsyncLifetime
shell.IsTerminalShowing.ShouldBeTrue();
}
/// <remarks>
/// The palette searches a host's vault name, and only where the row prints it — which a session holding
/// one vault never does. Matching it anyway would answer "personal" with the entire keychain, ranked
/// behind nothing and explained by nothing on screen. See <c>MainWindowViewModel.Rank</c>.
/// </remarks>
[Fact]
public async Task ThePalette_DoesNotMatchTheVaultNameWhenThereIsOnlyOneVaultToBeIn()
{
var vault = await ReadyToConnectAsync();
vault.VaultName.ShouldBe("Personal", "which is the word this test types");
shell.ToggleSearchCommand.Execute(null);
shell.SearchResults.ShouldHaveSingleItem()
.HasVaultBadge.ShouldBeFalse("one vault is nothing to tell apart");
shell.SearchText = "personal";
shell.SearchResults.ShouldBeEmpty();
}
/// <remarks>
/// The rail marks where you are, and a terminal is not one of its destinations. Lighting HOSTS while a
/// terminal fills the window would point at a screen that is not showing — and the selected tab already
@@ -8527,6 +8550,233 @@ public sealed class ShellFlowTests : IAsyncLifetime
raised.ShouldBeGreaterThan(0);
}
// ---- ◆ The path box, and the three things that can be done to a row ----
/// <remarks>
/// The way out of the breadcrumb's own reach. It can only offer what is under the directory already
/// listed, so before this box existed a path on the other side of the filesystem cost a walk to the
/// common ancestor and back down — a round trip a level — and one somebody already knew could not be
/// entered at all.
/// </remarks>
[Fact]
public async Task TypingAnAbsolutePathOnTheTransfersScreen_ListsIt()
{
var sftp = await ConnectedTransfersAsync();
shell.Transfers.RemotePathDraft = "/etc/nginx";
await shell.Transfers.GoToTypedRemotePathCommand.ExecuteAsync(null);
shell.Transfers.RemotePath.ShouldBe("/etc/nginx");
sftp.Listed[^1].ShouldBe("/etc/nginx");
}
/// <remarks>
/// Relative to the pane rather than to the session's own working directory, which is the distinction
/// <see cref="SftpPath.Resolve"/> exists for: handing the server a relative path would resolve it
/// somewhere the breadcrumb above the box did not predict.
/// </remarks>
[Theory]
[InlineData("logs", "/home/deploy/logs")]
[InlineData("../shared", "/home/shared")]
[InlineData("~/.ssh", "/home/deploy/.ssh")]
public async Task TypingARelativePathOnTheTransfersScreen_TakesItFromWhereThePaneIs(
string typed, string expected)
{
await ConnectedTransfersAsync();
shell.Transfers.RemotePath.ShouldBe("/home/deploy", "the fake opens on the account's home");
shell.Transfers.RemotePathDraft = typed;
await shell.Transfers.GoToTypedRemotePathCommand.ExecuteAsync(null);
shell.Transfers.RemotePath.ShouldBe(expected);
}
/// <remarks>
/// Somebody who cleared the box and pressed Enter has not asked for anything, and the root is a long way
/// from where they were standing.
/// </remarks>
[Fact]
public async Task ClearingThePathBox_PutsThePathBackRatherThanGoingToTheRoot()
{
await ConnectedTransfersAsync();
shell.Transfers.RemotePathDraft = " ";
await shell.Transfers.GoToTypedRemotePathCommand.ExecuteAsync(null);
shell.Transfers.RemotePath.ShouldBe("/home/deploy");
shell.Transfers.RemotePathDraft.ShouldBe("/home/deploy");
}
/// <remarks>
/// Renaming asks first and then acts on the path the question named, not on the selection — the promise
/// <c>ConfirmDeleteRemoteAsync</c> already makes, kept here for the same reason: nothing between opening
/// the form and pressing its button may re-point it at another file.
/// </remarks>
[Fact]
public async Task RenamingARemoteEntry_KeepsItInPlaceUnderTheNewName()
{
var sftp = await ConnectedTransfersAsync();
shell.Transfers.SelectedRemoteEntry = shell.Transfers.RemoteEntries[0];
shell.Transfers.RenameRemoteCommand.Execute(null);
shell.Transfers.IsMovingRemote.ShouldBeTrue();
shell.Transfers.RemoteMoveTarget.ShouldBe("notes.txt", "it opens on the name that changes nothing");
shell.Transfers.RemoteMoveTarget = "notes.md";
await shell.Transfers.ConfirmMoveRemoteCommand.ExecuteAsync(null);
sftp.Renamed.ShouldHaveSingleItem().ShouldBe(("/home/deploy/notes.txt", "/home/deploy/notes.md"));
shell.Transfers.IsMovingRemote.ShouldBeFalse();
}
/// <remarks>
/// A separator in a name is a move wearing a rename's clothing, and the server would answer it with "no
/// such file" about a directory nobody meant to name. The form stays open, because what has to be
/// corrected is what was typed into it.
/// </remarks>
[Fact]
public async Task RenamingToANameWithASeparatorInIt_IsRefusedAndTheFormStaysOpen()
{
var sftp = await ConnectedTransfersAsync();
shell.Transfers.SelectedRemoteEntry = shell.Transfers.RemoteEntries[0];
shell.Transfers.RenameRemoteCommand.Execute(null);
shell.Transfers.RemoteMoveTarget = "archive/notes.txt";
await shell.Transfers.ConfirmMoveRemoteCommand.ExecuteAsync(null);
sftp.Renamed.ShouldBeEmpty();
shell.Transfers.IsMovingRemote.ShouldBeTrue();
shell.Transfers.Status.ShouldContain("cannot contain");
}
/// <remarks>
/// A move keeps the name and changes the directory, which is the half of the pair a rename cannot do.
/// The destination is resolved the way the path box's is, so <c>../shared</c> means what it would mean
/// in a shell rather than being handed to the server as typed.
/// </remarks>
[Fact]
public async Task MovingARemoteEntry_KeepsItsNameAndTakesTheTypedDirectory()
{
var sftp = await ConnectedTransfersAsync();
shell.Transfers.SelectedRemoteEntry = shell.Transfers.RemoteEntries[0];
shell.Transfers.MoveRemoteCommand.Execute(null);
shell.Transfers.RemoteMoveTarget.ShouldBe("/home/deploy", "it opens on the directory it is in");
shell.Transfers.RemoteMoveTarget = "../shared";
await shell.Transfers.ConfirmMoveRemoteCommand.ExecuteAsync(null);
sftp.Renamed.ShouldHaveSingleItem().ShouldBe(("/home/deploy/notes.txt", "/home/shared/notes.txt"));
}
/// <remarks>
/// The destination that changes nothing. SFTP would answer it with success and a file that had not
/// moved, which reads as a move that silently did not happen.
/// </remarks>
[Fact]
public async Task MovingARemoteEntryIntoTheDirectoryItIsAlreadyIn_IsRefused()
{
var sftp = await ConnectedTransfersAsync();
shell.Transfers.SelectedRemoteEntry = shell.Transfers.RemoteEntries[0];
shell.Transfers.MoveRemoteCommand.Execute(null);
await shell.Transfers.ConfirmMoveRemoteCommand.ExecuteAsync(null);
sftp.Renamed.ShouldBeEmpty();
shell.Transfers.Status.ShouldContain("already there");
}
/// <remarks>
/// The three questions are one at a time by construction — each one's own opening clears the others — so
/// that no row can have two forms open over it and no button can arm a second question behind the first.
/// </remarks>
[Fact]
public async Task OpeningTheRenameForm_TakesAwayADeletionThatWasBeingAskedAbout()
{
await ConnectedTransfersAsync();
shell.Transfers.SelectedRemoteEntry = shell.Transfers.RemoteEntries[0];
shell.Transfers.DeleteRemoteCommand.Execute(null);
shell.Transfers.IsConfirmingRemoteDeletion.ShouldBeTrue();
shell.Transfers.RenameRemoteCommand.Execute(null);
shell.Transfers.IsConfirmingRemoteDeletion.ShouldBeFalse();
shell.Transfers.IsMovingRemote.ShouldBeTrue();
shell.Transfers.CanDeleteRemote.ShouldBeFalse("a question is on screen");
}
/// <remarks>
/// The pane used to go on showing the directory as it was before the file arrived, so the only way to
/// see something this application had just sent was to press REFRESH — the application asking to be
/// told about what it had done itself.
/// </remarks>
[Fact]
public async Task AnUploadThatLandsInTheDirectoryShowing_ReReadsItWithoutBeingAsked()
{
var sftp = await ConnectedTransfersAsync();
var before = sftp.Listed.Count;
shell.Transfers.NoteTransferLanded(Landed("/home/deploy/build.tar.gz"));
sftp.Listed.Count.ShouldBe(before + 1);
sftp.Listed[^1].ShouldBe("/home/deploy");
shell.Transfers.RemoteListingIsStale.ShouldBeFalse();
}
/// <remarks>
/// Only the directory on screen. A queue moving a hundred files into somewhere nobody is looking at
/// would otherwise be a round trip per file for a listing that changed nothing anybody can see.
/// </remarks>
[Fact]
public async Task AnUploadThatLandsSomewhereElse_ChangesNothingOnScreen()
{
var sftp = await ConnectedTransfersAsync();
var before = sftp.Listed.Count;
shell.Transfers.NoteTransferLanded(Landed("/srv/releases/build.tar.gz"));
sftp.Listed.Count.ShouldBe(before);
shell.Transfers.RemoteListingIsStale.ShouldBeFalse();
}
/// <remarks>
/// The refresh waits rather than interrupting. Re-listing under an open question is how the row somebody
/// answered about stops being the row that gets acted on — so the staleness is remembered and settled
/// when the question goes.
/// </remarks>
[Fact]
public async Task AnUploadThatLandsWhileAQuestionIsOpen_WaitsForItToBeAnswered()
{
var sftp = await ConnectedTransfersAsync();
shell.Transfers.SelectedRemoteEntry = shell.Transfers.RemoteEntries[0];
shell.Transfers.DeleteRemoteCommand.Execute(null);
var before = sftp.Listed.Count;
shell.Transfers.NoteTransferLanded(Landed("/home/deploy/build.tar.gz"));
sftp.Listed.Count.ShouldBe(before, "nothing may pull the listing out from under an open question");
shell.Transfers.RemoteListingIsStale.ShouldBeTrue();
await shell.Transfers.CancelDeleteRemoteCommand.ExecuteAsync(null);
sftp.Listed.Count.ShouldBe(before + 1);
shell.Transfers.RemoteListingIsStale.ShouldBeFalse();
}
/// <remarks>
/// A bucket is an <c>IRemoteFileStore</c> with no <c>HostSecret</c> underneath it, so there is no
/// <c>PinnedPaths</c> to read at all — see <see cref="TransfersViewModel.OpenBucketAsync"/>'s own remark.
@@ -9132,4 +9382,39 @@ public sealed class ShellFlowTests : IAsyncLifetime
return vault;
}
/// <summary>A transfers screen connected to the fixture's host, and the session it opened.</summary>
private async Task<FakeSftpSession> ConnectedTransfersAsync()
{
var vault = await ReadyToConnectAsync();
shell.Transfers.Attach(vault, knownHosts);
shell.Transfers.SelectedHost = shell.Transfers.Hosts[0];
await shell.Transfers.ConnectCommand.ExecuteAsync(null);
shell.Transfers.IsConnected.ShouldBeTrue(shell.Transfers.Status);
return ssh.OpenedSftp.ShouldNotBeNull();
}
/// <summary>An upload that has just finished, as the queue would report it.</summary>
/// <remarks>
/// Built here rather than run through <c>FileTransferQueue</c>, because what is asserted is what the
/// screen does when a transfer lands and not that a transfer can land: the queue's own path from
/// enqueued to completed is covered against a fuller fake in <c>DodoSSH.Client.Transfer.Tests</c>, and
/// running one here would put a thread-pool hand-off and this fixture's own dispatcher-less posting
/// between the event and the assertion.
/// </remarks>
private static TransferSnapshot Landed(string remotePath) => new(
Guid.CreateVersion7(),
TransferDirection.Upload,
SftpPath.Name(remotePath),
Path.Combine(Path.GetTempPath(), SftpPath.Name(remotePath)),
remotePath,
128,
128,
TransferState.Completed,
BytesPerSecond: 0,
Failure: null);
}
@@ -1,6 +1,7 @@
using System.Collections.Concurrent;
using DodoSSH.Client.Shell.ViewModels;
using DodoSSH.Client.Ssh;
using DodoSSH.Client.Transfer;
using NSubstitute;
namespace DodoSSH.Client.App.Tests;
@@ -281,6 +282,71 @@ public sealed class TransferQueueingTests : IDisposable
delivered.ShouldBe(0);
}
/// <remarks>
/// <para>
/// The local half of the automatic refresh. A download that finished left this pane showing the folder
/// as it was before the file arrived, so the file this application had just fetched was not in the
/// listing it was fetched into — and the way to see it was to press REFRESH.
/// </para>
/// <para>
/// Synchronous, unlike its remote counterpart, and that is the whole reason it is nothing more than a
/// re-read where it stands: a local listing is a filesystem call, so there is no round trip to defer and
/// no busy state to wait out. See <c>TransfersViewModel.SettleRemoteListingAsync</c> for the other side.
/// </para>
/// </remarks>
[Fact]
public void ADownloadThatLandsInTheFolderShowing_ReReadsItWithoutBeingAsked()
{
Connected();
transfers.RefreshLocalCommand.Execute(null);
transfers.LocalEntries.ShouldBeEmpty();
var landed = File("fetched.bin");
transfers.NoteTransferLanded(new TransferSnapshot(
Guid.CreateVersion7(),
TransferDirection.Download,
"fetched.bin",
landed,
"/srv/app/fetched.bin",
128,
128,
TransferState.Completed,
BytesPerSecond: 0,
Failure: null));
transfers.LocalEntries.Select(row => row.Name).ShouldBe(["fetched.bin"]);
}
/// <remarks>
/// Only the folder on screen, for the reason its remote counterpart gives: a queue writing into
/// somewhere nobody is looking at would otherwise re-read a directory per completed transfer.
/// </remarks>
[Fact]
public void ADownloadThatLandsSomewhereElse_ChangesNothingOnScreen()
{
Connected();
transfers.RefreshLocalCommand.Execute(null);
File("elsewhere.bin");
transfers.NoteTransferLanded(new TransferSnapshot(
Guid.CreateVersion7(),
TransferDirection.Download,
"elsewhere.bin",
Path.Combine(Path.GetTempPath(), "somewhere-else", "elsewhere.bin"),
"/srv/app/elsewhere.bin",
128,
128,
TransferState.Completed,
BytesPerSecond: 0,
Failure: null));
transfers.LocalEntries.ShouldBeEmpty();
}
/// <summary>The queue's rows, once the posts that create them have been let run.</summary>
/// <remarks>
/// <c>TransfersViewModel</c> adds a row from the transfer queue's own <c>Changed</c> event, which it
@@ -766,6 +766,59 @@ public sealed class VaultSharingTests : IAsyncLifetime
vault.Status.ShouldContain("left alone", Case.Insensitive);
}
/// <remarks>
/// <para>
/// The palette reaches every vault the session holds a key for, so the vault's name is one of the things
/// somebody can reasonably type into it: "show me the team's machines" is a question a list spanning two
/// vaults invites, and until now the only answer was to know one of the machines by name already.
/// </para>
/// <para>
/// The order is the assertion that matters. A vault name is the widest of the three readings — one word
/// matches every host in that vault at once — so the host whose own name carries the word has to come
/// first, or typing a machine's name would bury it under everybody else's.
/// </para>
/// </remarks>
[Fact]
public async Task ThePalette_FindsAHostByItsVaultsName_BehindOneCalledThatItself()
{
await UnlockedAsync();
var vaults = shell.Vaults;
await CreateVaultAsync(vaults, "Platform secrets");
var vault = shell.Vault!;
var sharedVaultId = vaults.SelectedVault!.VaultId;
await vault.LoadAsync(Token);
vault.NewHostCommand.Execute(null);
vault.EditorLabel = "platform-gateway";
vault.EditorHostname = "gateway.internal";
await vault.SaveHostCommand.ExecuteAsync(null);
vault.NewHostCommand.Execute(null);
vault.EditorSelectedVault =
vault.EditorVaultChoices.Single(choice => choice.VaultId == sharedVaultId);
vault.EditorLabel = "prod-db";
vault.EditorHostname = "db.internal";
await vault.SaveHostCommand.ExecuteAsync(null);
vault.IsEditing.ShouldBeFalse(vault.Status);
shell.ToggleSearchCommand.Execute(null);
shell.SearchText = "platform";
shell.SearchResults
.Select(row => row.Label)
.ShouldBe(["platform-gateway", "prod-db"], "a host's own name outranks its vault's");
shell.SearchResults[1].VaultBadge.ShouldBe(
"PLATFORM SECRETS", "and the row says what it was found by");
}
/// <summary>
/// Two hosts for the run above: one in the personal vault under a group, one already in the destination.
/// </summary>
@@ -58,6 +58,58 @@ public sealed class RemotePathTests
SftpPath.Trail("/").ShouldBeEmpty();
}
/// <remarks>
/// The four shapes the file browser's path box has to take, because they are the four a shell takes and
/// somebody typing a path into a box is typing what they would type into a shell.
/// </remarks>
[Theory]
[InlineData("/var/log", "/etc/nginx", "/etc/nginx")]
[InlineData("/var/log", "nginx", "/var/log/nginx")]
[InlineData("/var/log", "../lib", "/var/lib")]
[InlineData("/var/log", "./nginx/", "/var/log/nginx")]
public void Resolve_TakesAbsoluteRelativeAndDotted(string current, string typed, string expected)
{
SftpPath.Resolve(current, typed).ShouldBe(expected);
}
[Theory]
[InlineData("~", "/home/dodo")]
[InlineData("~/.ssh", "/home/dodo/.ssh")]
public void Resolve_ExpandsHomeWhenTheSessionHasSaidWhatItIs(string typed, string expected)
{
SftpPath.Resolve("/var/log", typed, "/home/dodo").ShouldBe(expected);
}
/// <remarks>
/// A directory really can be called <c>~</c>, and a session that has not said where home is has nothing
/// to expand it to. Guessing would send somebody to a path nobody typed.
/// </remarks>
[Fact]
public void Resolve_LeavesHomeAloneWhenNothingHasSaidWhereItIs()
{
SftpPath.Resolve("/var/log", "~/keys").ShouldBe("/var/log/~/keys");
}
/// <remarks>
/// A blank box is not a request to go to the root, which is where "resolve nothing against the current
/// directory" would otherwise land somebody who cleared the box and pressed Enter.
/// </remarks>
[Fact]
public void Resolve_AnswersTheCurrentDirectoryForNothingTyped()
{
SftpPath.Resolve("/var/log", " ").ShouldBe("/var/log");
}
/// <remarks>
/// Above the root is the root, as it is in every shell. The alternative is a path with no leading
/// separator, which is not a remote path at all.
/// </remarks>
[Fact]
public void Resolve_StopsClimbingAtTheRoot()
{
SftpPath.Resolve("/var", "../../../..").ShouldBe("/");
}
[Fact]
public void PosixMode_RendersTheKindCharacterAndThreeTriples()
{
@@ -4,10 +4,44 @@
The throughput and backpressure harness the plan requires before any UI exists. Nothing
here needs a WebView: the flow control is what is most likely to be wrong, and it is pure
logic once ITerminalTransport is a seam.
And, since RendererReconnectionTests, the renderer's own half of the same protocol — the page
that reads these frames, run as a script rather than described in C#. It lives here rather than
in a test project of the shell's own because this is where the other end of the socket is
tested, and the two halves of "the renderer stays attached" are one mechanism: the host takes
a second upgrade over the first, and the page is what makes that second upgrade happen. A
project for the shell would still need a reference to this one's subject to say anything.
-->
<ItemGroup>
<ProjectReference Include="../../src/DodoSSH.Client.Terminal/DodoSSH.Client.Terminal.csproj" />
</ItemGroup>
<ItemGroup>
<!--
A JavaScript engine, so terminal.js can be run as it ships instead of transcribed into C#.
See RendererPage for the trade against a node script, and for what an engine that is not
Chromium can and cannot prove.
-->
<PackageReference Include="Jint" />
</ItemGroup>
<ItemGroup>
<!--
◆ THE PAGE IS COPIED OUT OF THE SHELL PROJECT, WHICH IS THE ONE ODD THING IN THIS FILE.
Reaching across for a source file is not something else here does, and the alternatives are
worse: referencing DodoSSH.Client.Shell would drag Avalonia into a suite that draws nothing,
and a copy of the page checked in beside the tests would be a copy — the thing that quietly
stops matching what ships, which is precisely the failure this test exists to catch.
PreserveNewest rather than Always so that editing the page is what rebuilds it.
-->
<None Include="../../src/DodoSSH.Client.Shell/WebAssets/terminal.js"
Link="Renderer/terminal.js"
CopyToOutputDirectory="PreserveNewest" />
<None Include="Renderer/renderer-harness.js" CopyToOutputDirectory="PreserveNewest" />
</ItemGroup>
</Project>
@@ -0,0 +1,222 @@
'use strict';
/*
The world terminal.js is loaded into by RendererReconnectionTests.
It fakes exactly what the page's transport touches and nothing else: a WebSocket whose every step is
driven from the test, a clock that only moves when a test moves it, and the two DOM objects the page
reads at load. There is no Terminal, no fit addon and no WebGL here, because nothing on the reconnection
path builds a pane — a test that opens a session will have to add them, and should, rather than this
file guessing now at what such a test would want.
◆ NOTHING HERE MAY DECLARE A NAME terminal.js ALSO DECLARES.
Both files are evaluated as scripts into the same global scope, and the page's own `const root` against
a `var root` here is a SyntaxError before a line of either runs. That is why the page's two elements are
`pageRoot` and `pageBanner` below and reached through getElementById, which is how the page reaches them
anyway.
◆ AND THE FAKE SOCKET'S BEHAVIOUR IS THE PART TO GET RIGHT.
close() is the one method with a rule that is not obvious and that the tests lean on: a socket closed
while it is still CONNECTING never fires 'close' at all, per the WebSocket specification, while one
closed after it opened does. The page relies on exactly that — connect() closes the attempt it abandons
and expects to hear nothing back from it — so a fake that fired 'close' either way would report the loop
the page's guards exist to prevent, and one that fired it neither way would hide it.
*/
var clock = { now: 0, next: 1, timers: {} };
/** Every socket the page has opened, in order, live or dead. */
var sockets = [];
function listeners(target) {
target.handlers = {};
target.addEventListener = function (name, handler) {
if (!target.handlers[name]) {
target.handlers[name] = [];
}
target.handlers[name].push(handler);
};
target.fire = function (name) {
var handlers = target.handlers[name] || [];
for (var i = 0; i < handlers.length; i++) {
handlers[i]({});
}
};
return target;
}
function FakeSocket(url, protocols) {
this.url = url;
this.protocols = protocols;
this.readyState = FakeSocket.CONNECTING;
this.binaryType = '';
listeners(this);
sockets.push(this);
}
FakeSocket.CONNECTING = 0;
FakeSocket.OPEN = 1;
FakeSocket.CLOSING = 2;
FakeSocket.CLOSED = 3;
FakeSocket.prototype.send = function () {};
/** What the page calls. See the note above on why a connecting socket goes quietly. */
FakeSocket.prototype.close = function () {
if (this.readyState === FakeSocket.CLOSED) {
return;
}
var wasConnecting = this.readyState === FakeSocket.CONNECTING;
this.readyState = FakeSocket.CLOSED;
if (!wasConnecting) {
this.fire('close');
}
};
var pageBanner = { textContent: 'Connecting…' };
var pageRoot = listeners({
dataset: { token: 'test-token', socket: 'ws://127.0.0.1:1/socket' },
appendChild: function () {},
});
var document = listeners({
hidden: false,
getElementById: function (id) { return id === 'root' ? pageRoot : pageBanner; },
createElement: function () { return { dataset: {}, style: {}, remove: function () {} }; },
});
var window = listeners({});
// The page warns through this on paths no reconnection test reaches. Present so that a test which does
// reach one fails on its own assertion rather than on a missing global.
var console = { warn: function () {}, log: function () {} };
function setTimeout(callback, delay) {
var id = clock.next++;
clock.timers[id] = { at: clock.now + (delay || 0), callback: callback };
return id;
}
function clearTimeout(id) {
delete clock.timers[id];
}
function ResizeObserver() {
this.observe = function () {};
}
// ── What the tests drive the page with ──────────────────────────────────────────────────────────────
/**
* Runs every timer due within the next `ms`, in the order they fall due.
*
* One at a time and re-scanned each round rather than collected up front, because a timer's callback
* routinely schedules the next one — which is the whole shape of the page's retry — and a snapshot taken
* before the first callback ran would miss it.
*/
function advance(ms) {
var target = clock.now + ms;
for (;;) {
var dueId = null;
var due = null;
for (var id in clock.timers) {
var timer = clock.timers[id];
if (timer.at <= target && (due === null || timer.at < due.at)) {
due = timer;
dueId = id;
}
}
if (due === null) {
break;
}
delete clock.timers[dueId];
clock.now = due.at;
due.callback();
}
clock.now = target;
}
/** How many sockets the page has opened since it loaded. */
function attempts() {
return sockets.length;
}
/** What the one status element says — the banner the user sees. */
function banner() {
return pageBanner.textContent;
}
/** Whether that attempt has been closed, by the page or by the far end. */
function isClosed(index) {
return sockets[index].readyState === FakeSocket.CLOSED;
}
/** The host accepted the upgrade. */
function accept(index) {
sockets[index].readyState = FakeSocket.OPEN;
sockets[index].fire('open');
}
/** An established socket goes away and the page is told. */
function drop(index) {
sockets[index].readyState = FakeSocket.CLOSED;
sockets[index].fire('close');
}
/** An attempt that never connects: 'error' then 'close', as a refused connection reports itself. */
function fail(index) {
sockets[index].readyState = FakeSocket.CLOSED;
sockets[index].fire('error');
sockets[index].fire('close');
}
/**
* A close arriving for a socket that died earlier — the host's takeover abort, landing late.
*
* Separate from drop() because the point of it is the delay: the socket is already dead by the time the
* event is delivered, which is what a suspended renderer's queued events look like on the way back.
*/
function deliverLateClose(index) {
sockets[index].readyState = FakeSocket.CLOSED;
sockets[index].fire('close');
}
/** The screen the page is on goes away, and comes back. */
function becomeHidden() {
document.hidden = true;
document.fire('visibilitychange');
}
function becomeVisible() {
document.hidden = false;
document.fire('visibilitychange');
}
function takeFocus() {
window.fire('focus');
}
function comeOnline() {
window.fire('online');
}
var WebSocket = FakeSocket;
@@ -0,0 +1,79 @@
using System.Globalization;
using Jint;
namespace DodoSSH.Client.Terminal.Tests;
/// <summary>
/// One load of <c>terminal.js</c>, in a fake browser, for one test.
/// </summary>
/// <remarks>
/// <para>
/// <b>The page's own source is what runs.</b> Not a transcription of its logic into C# — that would test a
/// copy, and the copy would be the thing that stayed correct. The file is read from the shell project and
/// evaluated as it ships, so a change to the page that breaks the reconnection rules fails here.
/// </para>
/// <para>
/// <b>Jint rather than node, and that is a deliberate trade.</b> A node script would be the obvious way to
/// run JavaScript and would need node on every machine and in every CI job that runs the suite — so it
/// would be a second test command, run separately, and the first thing to be forgotten. This runs inside
/// <c>dotnet test</c> with everything else. What it costs is that the engine is not the engine the page
/// actually runs in: Jint is not Chromium, so this can prove the page's own logic and can prove nothing
/// about how WebView2 or Android's WebView behave. That boundary is exactly where
/// <c>docs/manual-checks.md</c> picks up — see 1.10 and 11.12a.
/// </para>
/// <para>
/// A fresh engine per test, because the page is a script with module-level state and there is no unloading
/// it: two tests sharing one engine would share a socket list, a clock and a backoff.
/// </para>
/// </remarks>
internal sealed class RendererPage
{
private readonly Engine engine;
private RendererPage(Engine engine) => this.engine = engine;
/// <summary>How many sockets the page has opened since it loaded.</summary>
/// <remarks>
/// The measurement nearly every test here turns on, and it is deliberately a count of *attempts*
/// rather than of live sockets: the failures being guarded against are a page that stops trying and a
/// page that never stops, and both are counted rather than observed.
/// </remarks>
public int Attempts => (int)engine.Evaluate("attempts()").AsNumber();
/// <summary>What the status element says — the banner a user would be looking at.</summary>
public string Banner => engine.Evaluate("banner()").AsString();
/// <summary>
/// Loads the harness and then the page, leaving the page exactly as it is a moment after the WebView
/// navigated to it: one socket opened and still connecting.
/// </summary>
public static RendererPage Load()
{
var browser = new Engine();
// Order matters and is not incidental: the page connects on its last line, so every global it
// touches — the socket constructor above all — has to be in place before it is evaluated.
browser.Execute(Read("Renderer/renderer-harness.js"));
browser.Execute(Read("Renderer/terminal.js"));
return new RendererPage(browser);
}
/// <summary>Runs a line of the harness's own vocabulary — <c>accept(0)</c>, <c>advance(1000)</c>.</summary>
public void Do(string script) => engine.Execute(script);
/// <summary>Whether that attempt has been closed, by the page or by the far end.</summary>
public bool IsClosed(int attempt) =>
engine.Evaluate(
string.Create(CultureInfo.InvariantCulture, $"isClosed({attempt})"))
.AsBoolean();
/// <remarks>
/// Both files are copied beside the test assembly by the project file, the page out of the shell
/// project it belongs to. Read from disk rather than embedded so that the copy which runs here is the
/// same bytes the host serves, with nothing in between that could go stale.
/// </remarks>
private static string Read(string relativePath) =>
File.ReadAllText(Path.Combine(AppContext.BaseDirectory, relativePath));
}
@@ -0,0 +1,192 @@
namespace DodoSSH.Client.Terminal.Tests;
/// <summary>
/// The renderer page's half of staying attached — <c>terminal.js</c>'s <c>connect()</c> and what drives it.
/// </summary>
/// <remarks>
/// <para>
/// The host's half is <see cref="TerminalDataPlaneTests"/>, and the two are one mechanism: a socket that
/// drops is ordinary here, and the page coming back for another is what makes it ordinary. What these
/// tests protect is the property that failure of this mechanism has no other symptom — a terminal whose
/// page has given up looks exactly like a terminal whose remote has gone quiet, except for a line of text
/// nobody reads twice.
/// </para>
/// <para>
/// Four of these were written against a page that failed them — the stale close, the handshake that never
/// finishes, and the two wake-ups — and the rest describe behaviour that was already right and is easy to
/// break while fixing those. The two that assert a wake-up does *nothing* pass against either version,
/// which is the point of them: they are what stops the cure being worse, and they can only ever fail
/// against a future change. See <see cref="RendererPage"/> for how the real file is loaded and for what
/// this cannot reach.
/// </para>
/// </remarks>
public sealed class RendererReconnectionTests
{
[Fact]
public void ThePage_ConnectsWhenItLoads()
{
var page = RendererPage.Load();
page.Attempts.ShouldBe(1);
}
[Fact]
public void ADroppedSocket_IsRetriedAndTheBannerClears()
{
var page = RendererPage.Load();
page.Do("accept(0)");
page.Banner.ShouldBe("");
page.Do("drop(0)");
page.Banner.ShouldStartWith("Reconnecting");
page.Do("advance(1000)");
page.Attempts.ShouldBe(2);
page.Do("accept(1)");
page.Banner.ShouldBe("");
}
/// <remarks>
/// The wait grows within one outage and goes back to a second once a socket has actually opened, so
/// that the next outage is not paid for at the previous one's rate.
/// </remarks>
[Fact]
public void TheWait_GrowsWithinAnOutageAndResetsAfterIt()
{
var page = RendererPage.Load();
page.Do("fail(0); advance(1000)");
page.Attempts.ShouldBe(2);
page.Do("fail(1); advance(1999)");
page.Attempts.ShouldBe(2);
page.Do("advance(1)");
page.Attempts.ShouldBe(3);
page.Do("accept(2); drop(2); advance(1000)");
page.Attempts.ShouldBe(4);
}
/// <summary>
/// A close for a socket the page has already replaced must not start a reconnect.
/// </summary>
/// <remarks>
/// The loop this forbids costs nothing to enter and never leaves: the host aborts the displaced socket
/// on every takeover — see <c>TerminalDataPlane.UpgradeAsync</c> — so a stale close that schedules a
/// retry displaces the socket that has just succeeded, whose own close schedules the next. The visible
/// end of it is a terminal that reconnects every second forever with the banner up for most of it.
/// </remarks>
[Fact]
public void AStaleClose_DoesNotDisplaceTheSocketThatSucceeded()
{
var page = RendererPage.Load();
page.Do("accept(0); drop(0); advance(1000)");
page.Do("accept(1)");
page.Attempts.ShouldBe(2);
// The first socket's end, arriving after the page has moved on.
page.Do("deliverLateClose(0)");
page.Do("advance(60000)");
page.Attempts.ShouldBe(2);
page.Banner.ShouldBe("");
}
/// <summary>
/// An attempt that never finishes its handshake is given up on rather than waited on forever.
/// </summary>
/// <remarks>
/// Every other retry in the page is scheduled by a close or an error, so a socket that reports neither
/// — which is what a renderer suspended mid-handshake leaves behind — used to schedule nothing at all.
/// The page then held a banner saying it was reconnecting with no timer pending and no socket coming,
/// for the rest of its life.
/// </remarks>
[Fact]
public void AHandshakeThatNeverFinishes_IsAbandonedAndRetried()
{
var page = RendererPage.Load();
// Nothing whatever from the first attempt: no open, no error, no close.
page.Do("advance(5000)");
page.Attempts.ShouldBe(1);
page.Do("advance(1000)");
page.Attempts.ShouldBe(2);
page.IsClosed(0).ShouldBeTrue();
page.Do("accept(1)");
page.Banner.ShouldBe("");
}
/// <summary>
/// Coming back to the page reconnects it, without waiting for a timer that may not be running.
/// </summary>
/// <remarks>
/// The case the whole wake-up path exists for, and the one a test can only approximate: the harness's
/// clock stands still here because a real hidden page's clock is throttled rather than stopped, and
/// standing still is the honest worst case of that. What is being asserted is that the page does not
/// need the clock at all to notice it is back.
/// </remarks>
[Fact]
public void BecomingVisibleAgain_ReconnectsWithoutTheTimer()
{
var page = RendererPage.Load();
page.Do("accept(0); becomeHidden(); drop(0)");
page.Attempts.ShouldBe(1);
page.Do("becomeVisible()");
page.Attempts.ShouldBe(2);
// And the timer that was pending when the page woke must not open a third socket on top of the
// one that just succeeded — which would be the takeover loop, entered from the other side.
page.Do("accept(1); advance(60000)");
page.Attempts.ShouldBe(2);
page.Banner.ShouldBe("");
}
[Fact]
public void TakingTheKeyboardBack_AlsoReconnects()
{
var page = RendererPage.Load();
page.Do("accept(0); drop(0); takeFocus()");
page.Attempts.ShouldBe(2);
}
/// <remarks>
/// The wake-ups fire on gestures as ordinary as clicking the window, so the check they make has to be
/// the thing that keeps them cheap rather than the frequency. A page whose socket is up must treat all
/// of them as nothing at all — anything else would be the takeover loop with a person's mouse driving it.
/// </remarks>
[Fact]
public void WakingUpOverAHealthySocket_DoesNothing()
{
var page = RendererPage.Load();
page.Do("accept(0)");
page.Do("takeFocus(); becomeVisible(); comeOnline(); becomeHidden(); becomeVisible()");
page.Attempts.ShouldBe(1);
page.Banner.ShouldBe("");
}
/// <remarks>
/// An attempt already in flight is left to finish or to time out. Restarting it on every wake-up would
/// mean a page being clicked during a slow handshake never completing one.
/// </remarks>
[Fact]
public void WakingUpWhileConnecting_LeavesTheAttemptAlone()
{
var page = RendererPage.Load();
page.Do("takeFocus(); becomeVisible(); comeOnline()");
page.Attempts.ShouldBe(1);
}
}
@@ -416,6 +416,36 @@ public sealed class TerminalDataPlaneTests : IAsyncDisposable
TimeProvider.System,
new TerminalPumpOptions { FlushInterval = TimeSpan.FromMilliseconds(10) });
/// <summary>
/// Opens a renderer's socket and returns once the plane is actually holding it.
/// </summary>
/// <remarks>
/// <para>
/// <b>Connected and attached are two different moments, and the gap between them is where this used to
/// flake.</b> <c>ClientWebSocket.ConnectAsync</c> completes on the 101, which
/// <see cref="TerminalDataPlane.UpgradeAsync"/> writes before it has a <see cref="WebSocket"/> to
/// attach — it builds one from the stream and swaps it in a few instructions later, on the accept
/// thread. A frame sent in between is dropped, by design rather than by accident: the transport has
/// nowhere to put a frame for a renderer that is not there, and queueing it is the unbounded growth the
/// credit window exists to prevent.
/// </para>
/// <para>
/// So a test that connected and immediately expected a frame was racing that window on every run. It
/// lost one on CI — <c>Output_ReachesTheRenderer</c> read the output frame first and asked why it was
/// not the session's opening one, the opening one having been dropped a moment earlier — which is a
/// scheduling accident on a loaded machine and says nothing whatever about the transport.
/// </para>
/// <para>
/// Production does not race it and needs no change: everything that opens a session waits on
/// <c>TerminalWorkspace.WaitForRendererAsync</c> first, and that resolves from the same few lines this
/// event is raised from.
/// </para>
/// <para>
/// Subscribed before the connection rather than after it, because the event is raised on the accept
/// thread and can be over before <c>ConnectAsync</c> has returned here. Bounded, so that a socket that
/// never attaches fails this helper rather than hanging the suite in a later receive.
/// </para>
/// </remarks>
private async Task<ClientWebSocket> ConnectAsync(
string? token = "",
string? origin = null)
@@ -433,17 +463,31 @@ public sealed class TerminalDataPlaneTests : IAsyncDisposable
"Origin",
origin ?? string.Create(CultureInfo.InvariantCulture, $"http://127.0.0.1:{plane.Port}"));
var attached = new TaskCompletionSource(TaskCreationOptions.RunContinuationsAsynchronously);
void OnAttached(object? sender, EventArgs e) => attached.TrySetResult();
plane.SocketAttached += OnAttached;
try
{
await socket.ConnectAsync(
new Uri($"ws://127.0.0.1:{plane.Port}{TerminalDataPlane.SocketPath}"),
TestContext.Current.CancellationToken);
await attached.Task.WaitAsync(
TimeSpan.FromSeconds(5),
TestContext.Current.CancellationToken);
}
catch
{
socket.Dispose();
throw;
}
finally
{
plane.SocketAttached -= OnAttached;
}
return socket;
}
@@ -538,10 +538,26 @@ public sealed class TerminalWorkspaceTests
new("host.invalid", 22, "dodo", new SshPasswordCredential("irrelevant"));
/// <remarks>
/// <para>
/// Attaches the way the real page does: by fetching the served page, reading the token and socket URL
/// back out of it, and presenting them on the upgrade — rather than reaching into the workspace for a
/// token it does not expose. A shortcut here would prove only that a socket can be opened, not that the
/// workspace serves a page a renderer could actually attach with.
/// </para>
/// <para>
/// And it waits for the attach rather than only for the handshake, for the reason
/// <c>TerminalDataPlaneTests.ConnectAsync</c> sets out at length: the 101 is written before the socket
/// is attachable, and a frame sent in between is dropped. A caller that opens a session on the socket
/// this returns and then reads its opening frame is exactly the shape that loses that race.
/// </para>
/// <para>
/// <c>WaitForRendererAsync</c> answers only for the first renderer ever to attach, so a second call
/// returns immediately without proving anything about the second socket. That is enough here and is
/// not luck: the only frames a second socket is given are the replay, and the replay is *caused* by the
/// attach — <see cref="TerminalWorkspace.RendererReattached"/> and the frames before it cannot be sent
/// early. The day a test sends something else down a reattached socket, this needs the data plane's own
/// <c>SocketAttached</c>, which the workspace does not forward today.
/// </para>
/// </remarks>
private static async Task<ClientWebSocket> ConnectRendererAsync(TerminalWorkspace workspace)
{
@@ -561,6 +577,8 @@ public sealed class TerminalWorkspaceTests
try
{
await client.ConnectAsync(new Uri(socketUrl), TestContext.Current.CancellationToken);
await workspace.WaitForRendererAsync(TestContext.Current.CancellationToken);
}
catch
{
@@ -2,6 +2,15 @@
"version": 2,
"dependencies": {
"net10.0": {
"Jint": {
"type": "Direct",
"requested": "[4.16.0, )",
"resolved": "4.16.0",
"contentHash": "YHofgoVtjWzqmG2GsGsp6eYMmcBfGgJOcH+Ki2UdZXNsYgKGnWrK2hSqRSPG/6HqeiipT5YPhzEH+bwxFO+YAQ==",
"dependencies": {
"Acornima": "1.7.0"
}
},
"Meziantou.Analyzer": {
"type": "Direct",
"requested": "[3.0.137, )",
@@ -48,6 +57,11 @@
"xunit.v3.mtp-v1": "[3.2.2]"
}
},
"Acornima": {
"type": "Transitive",
"resolved": "1.7.0",
"contentHash": "a2I4O4qkuAdB0oSaGz6/k0n/bXxMbGcLBra5dNTTVSLmTwM7uORA8ebpOrNMmDfFWOMwvuaRL6gPprRV4HTV0w=="
},
"Castle.Core": {
"type": "Transitive",
"resolved": "5.1.1",