Composite buffers in a pane, and three web UI faults - #3020
Open
sinelaw wants to merge 1 commit into
Open
Conversation
Four fixes to behaviour that predates the agent work, split out so they can be
reviewed without it.
A `pane` widget showed nothing for a composite buffer: side-by-side diffs go
through a separate render branch, which painted blank inside a panel.
The web UI's playwright suite had three, each hidden behind the one before it.
Its New Workspace step clicks "New Task… ▾" to open the create dropdown and then
the "New Task…" option; menu options are full-width buttons, so the option's
text is padded — " New Task… " — and Playwright does not trim
before testing a RegExp `hasText`. The anchored pattern matched nothing and the
click waited out its 30s, killing the run before anything after it. Verified
against a real browser: with that exact string `/New Task…$/` matches zero
elements and `/New Task…\s*$/` matches one. The anchor has to stay or `.first()`
takes the button that opened the menu and closes it again.
Behind that, the dock's toolbar was overflowing: the plugin sizes the search
field in terminal cells against the dock's column count, the web lays the dock
out in CSS pixels, and the two disagree — 457px of content in a 216px row. It
wrapped onto four lines and the session tree paid for them. The field shrinks
now and the button keeps its natural width; squeezing the button alone just
moved the wrap inside it.
And the dropdown highlight was the width of its text rather than the width of
the menu, because options are built as `col(...rows)` and both the CSS rule and
the test looked for `.w-row > .w-button`. The rule matched nothing; the test's
`closest('.w-row')` returned null and reported a failure that had nothing to do
with width. Both accept either container now.
Verified: the full web UI suite runs green (181 passed, 0 failed) against a real
browser, three times over.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01D22YhixLB4aPupLo5S2K9P
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Four fixes to behaviour that predates the agent-control-plane work, split out so they can be reviewed without it. #2962 is now stacked on this.
paneshowed nothing for a composite bufferSide-by-side diffs go through a separate render branch, which painted blank inside a panel.
Three faults in the web UI's playwright suite
Each was hidden behind the one before it — the first killed the run, so nothing after it had executed in a long time.
The New Workspace step could never find its menu option. It clicks
New Task… ▾to open the create dropdown, then theNew Task…option. Menu options are full-width buttons, so the option's real text is padded —" New Task… "— and Playwright does not trim before testing a RegExphasText. The anchored pattern matched nothing and the click waited out its full 30s timeout. Checked against a real browser rather than reasoned about:The anchor still has to stay: without it the pattern also matches the
New Task… ▾button that opened the menu, and.first()takes that one and closes the dropdown again.The dock's toolbar was overflowing. The plugin sizes the search field in terminal cells against the dock's column count; the web lays the dock out in CSS pixels, and the two do not agree — measured at 457px of content in a 216px row. It wrapped onto four lines and the session tree paid for them, which is what the "tree ≥ 55% of dock height" check was failing on. The field shrinks now and the button keeps its natural width. Squeezing the button alone was not enough — it just moved the wrap inside the button and cost the same row.
The dropdown highlight was the width of its text, not the width of the menu. Options are built as
col(...rows), so they land in a.w-col, but both the CSS rule and the test looked for.w-row > .w-button. The rule matched nothing, and the test'sclosest('.w-row')returned null — reporting a failure that had nothing to do with width. Both accept either container now.Verification
The full web UI suite runs green against a real browser — 181 passed, 0 failed — three consecutive times. (Running it locally needs loopback excluded from a proxy,
NO_PROXY=127.0.0.1,localhost, or Chromium proxies the bridge and the scene never populates.)Scope note
The hit-area column fix and the pane click/focus fixes are also pre-existing-behaviour fixes, but they could not come with this PR:
HitAreagains a requiredcolumnfield, which forces every construction site inwidget_runtime.rsto change, and that file's other changes need the widget vocabulary fromapi.rs. Separating them would have meant splittingapi.rshunk by hunk and landing API with no consumer. They stay in #2962.🤖 Generated with Claude Code
https://claude.ai/code/session_01D22YhixLB4aPupLo5S2K9P
Generated by Claude Code