View renderer (views/*): git-worktree entity cards overflow horizontally / path field does not wrap (MainWindow entity-pane, legacy entity-card-tree inner ScrollViewer) #1064

Related to #1049 (agent chat editor) and #1029, #1045.

Consolidation update (revised): #1064 originally proposed a targeted inline setter, then a consolidated attached-property style that set ScrollViewer.HorizontalScrollBarVisibility="Disabled" on TreeView.entity-card-tree. Disabled makes wrapping work, but it removes horizontal scrolling entirely — so when the viewport is narrower than the card's hard minimum widths, the card is clipped with no way to scroll to reach it. The maintainer correctly objected: "With horizontal scrolling disabled completely, how do we scroll horizontally to view cards when their minimum size must be respected?" This body replaces Disabled with the same two-regime wrapper #1049 proved for the sibling entity-card-tree-view, so the consolidated entity-card-tree style respects hard minimum widths and exposes a horizontal scrollbar precisely when the viewport drops below them — while still wrapping to the viewport when the viewport is wider. Everything below is proven headlessly in Avalonia 12.1.

Summary

In a saved View such as "Git Workspaces" / views/git-workspaces, the entity cards for git-worktree entities overflow horizontally: the long path value runs off the right edge, a horizontal scrollbar appears alongside the vertical one, and the text does not wrap to the viewport. The screenshot control is the View renderer: the entity-pane TreeView in Phantom.Workspaces/MainWindow.axaml (not the Entity Browser, not the agent chat editor). The same latent defect exists on every legacy entity-card-tree consumer whose inner scroller is left at Avalonia's default.

The consolidated fix makes any TreeView.entity-card-tree behave correctly by merely carrying the class, with two regimes:

• Viewport ≥ minimum widths: content caps to the viewport and wraps; no horizontal scrollbar.
• Viewport < minimum widths (~160px): the card keeps its hard minimum width and a single horizontal scrollbar appears so the minimum-width content is reachable; content wraps at the minimum.

This is the identical pattern #1049 shipped for entity-card-tree-view. Verified empirically with headless Avalonia 12.1 layout tests (measure + arrange + assert Bounds/Extent/Viewport), not by inspection.

Answering the maintainer's question directly

Horizontal scrolling is NOT globally disabled. The consolidated style keeps ScrollViewer.HorizontalScrollBarVisibility="Auto" and places one items-region wrapper around the whole items area with MinWidth = 160 (the summed hard minimums from #1045) and MaxWidth bound to the tree's own inner-scroller viewport width. That yields exactly two regimes:

1. Viewport ≥ 160 (normal/wide): MaxWidth = Viewport.Width caps the wrapper to the visible width. The measure is now finite, so Stretch fills and TextWrapping="Wrap" wraps. Extent == viewport ⇒ no horizontal scrollbar.
2. Viewport < 160 (narrower than the hard minimum): MinWidth (160) > MaxWidth (= Viewport.Width). Avalonia's layout clamp (min wins when min > max) resolves the wrapper to 160, wider than the viewport ⇒ extent > viewport ⇒ a single horizontal scrollbar appears, and you can scroll to reveal the card's minimum-width content. Content wraps at 160, never at infinity.

So the hard minimums are respected and always reachable: below the minimum you scroll horizontally; above it, the card caps to the viewport and wraps. The earlier Disabled-only variant is rejected precisely because in regime 2 it clips the card with no scrollbar.

Root Cause

The inner scroller of a TreeView.entity-card-tree defaults to HorizontalScrollBarVisibility="Auto", and there is no base TreeView.entity-card-tree rule configuring it (only TreeView.entity-card-tree-view, SharedStyles.axaml:265-278, has the #1049 wrapper). Under Auto, the ScrollContentPresenter sets CanHorizontallyScroll = true and measures content at double.PositiveInfinity width, so TextWrapping="Wrap" on the path value (workspace-field-read-value) is inert; the card grows to intrinsic width and the inner scroller shows a horizontal scrollbar.

Confirmed empirically (baseline): with the inner scroller at default Auto, a bare tree arranges the card to 2370px inside an 800px viewport, Extent.Width = 2370 > Viewport.Width = 800, and the path value stays a single 16px line. Wrapping the tree in an outer Disabled ScrollViewer does not help — the inner Auto scroller re-introduces the infinite measure.

Design / Fix (consolidated style — two-regime wrapper)

Recommendation: an attached-property style on TreeView.entity-card-tree that (a) sets H=Auto, and (b) provides a single items-region wrapper via ItemsPanel with MinWidth=160 and MaxWidth bound to $parent[ScrollViewer].Viewport.Width. Not Disabled; not the nested-template /template/ ScrollViewer#PART_ScrollViewer selector (the inner scroller is unnamed); not a full control-template replacement.

Add this canonical rule to Phantom.Workspaces.Gui.Shared/Styles/SharedStyles.axaml (identical mechanism to entity-card-tree-view at :265-278):

<!-- Consolidated (#1064): any TreeView.entity-card-tree respects the card's hard minimum
     widths AND stays reachable. H=Auto keeps a horizontal scrollbar available; a single
     items-region wrapper caps content to the inner scroller's viewport (so it wraps and
     never overflows when wide) but floors at MinWidth=160 (so a horizontal scrollbar appears
     and the minimum-width card is scrollable when the viewport is narrower than the minimum).
     The tree's own inner scroller supplies vertical scrolling; no surrounding ScrollViewer. -->
<Style Selector="TreeView.entity-card-tree">
    <Setter Property="ScrollViewer.HorizontalScrollBarVisibility" Value="Auto" />
    <Setter Property="ScrollViewer.VerticalScrollBarVisibility" Value="Auto" />
    <Setter Property="ScrollViewer.AllowAutoHide" Value="False" />
    <Setter Property="ItemsPanel">
        <ItemsPanelTemplate>
            <StackPanel Orientation="Vertical"
                        HorizontalAlignment="Stretch"
                        MinWidth="160"
                        MaxWidth="{Binding $parent[ScrollViewer].Viewport.Width}" />
        </ItemsPanelTemplate>
    </Setter>
</Style>

Recommended: single shared base style for both classes

entity-card-tree and entity-card-tree-view now use identical ScrollViewer config and the same wrapper. Consolidate them into one multi-selector rule (mirroring the shared TreeViewItem template at SharedStyles.axaml:236), keeping the entity-card-tree-view-only Background as a separate setter:

<Style Selector="TreeView.entity-card-tree, TreeView.entity-card-tree-view">
    <Setter Property="ScrollViewer.HorizontalScrollBarVisibility" Value="Auto" />
    <Setter Property="ScrollViewer.VerticalScrollBarVisibility" Value="Auto" />
    <Setter Property="ScrollViewer.AllowAutoHide" Value="False" />
    <Setter Property="ItemsPanel">
        <ItemsPanelTemplate>
            <StackPanel Orientation="Vertical" HorizontalAlignment="Stretch"
                        MinWidth="160"
                        MaxWidth="{Binding $parent[ScrollViewer].Viewport.Width}" />
        </ItemsPanelTemplate>
    </Setter>
</Style>
<Style Selector="TreeView.entity-card-tree-view">
    <Setter Property="Background" Value="{DynamicResource Theme.Surface.EntityPane.Background}" />
</Style>

This makes #1064 and #1049 share one authoritative wrapper. If a single shared base is preferred it is recommended; otherwise duplicate the entity-card-tree rule verbatim.

Which viewport-width source resolves (proven experimentally)

• $parent[ScrollViewer].Viewport.Width — WINNER (resolved, gutter-correct). From inside the ItemsPanel, the $parent[ScrollViewer] ancestor lookup resolves by TYPE to the templated inner (unnamed) ScrollViewer — the unnamed-ness that defeats #PART_ScrollViewer name selectors is irrelevant to a type-based ancestor lookup. Asserted: the wrapper's resolved MaxWidth equals the inner scroller's Viewport.Width (784 when a vertical scrollbar is present), i.e. it intrinsically excludes the vertical-scrollbar gutter, so content never sits under the scrollbar (entity-card-tree-view refinements: min-widths, indent column, sticky scope, blue-border Z-order, horizontal scrollbar, editor item word-wrap (follow-up to #1029) #1045).
• $parent[TreeView].Bounds.Width — also resolved, but REJECTED. It resolves to the tree's full laid-out width (800, including the gutter). It only avoids a spurious horizontal scrollbar because HorizontalAlignment="Stretch" re-caps the panel to the available viewport in arrange; its MaxWidth over-reports by the gutter and is less robust. Prefer the ScrollViewer.Viewport.Width source.
• ScrollViewer.Viewport attached-value — not needed; the ancestor-lookup binding is sufficient and is exactly what entity-card-tree-view: entity cards expand far beyond the viewport horizontally; must be capped to viewport width (follow-up to #1045) #1049 already ships.

Attached-property flow (unchanged from last round): the ScrollViewer.* attached properties set on the TreeView flow to the templated inner scroller — asserted HorizontalScrollBarVisibility = Auto, VerticalScrollBarVisibility = Auto, AllowAutoHide = false.

Pure-style solution — no fallback needed

The pure-style, name-free solution works: H=Auto via attached property + ItemsPanel wrapper with MinWidth + MaxWidth={Binding $parent[ScrollViewer].Viewport.Width}. No attached behavior, no named ScrollViewer, and no control-template replacement are required. (Had it failed, the minimal fallback would have been a one-line template tweak to name the inner ScrollViewer PART_ScrollViewer so MaxWidth="{Binding #PART_ScrollViewer.Viewport.Width}" could target it — but this was not necessary.)

Secondary — soften the fixed 200px label column (as in #1049)

At the narrow regime the wrapper floors at 160, but the field-row grids' fixed ColumnDefinitions="200,*" label column (WorkspaceDataTemplates.axaml) then starves the value column to 0 (empirically pathW=0, single line). With the label column softened to Auto,* (the #1049 secondary fix), the value column keeps room and the path wraps at the 160 min (empirically 84 × 428). The two-regime scrollbar behavior is correct either way; softening the label column is what lets the minimum-width content actually wrap rather than clip.

Why not the earlier variants

• Disabled-only (rejected/insufficient): wraps, but removes the horizontal scrollbar entirely, so below the minimum widths the card is clipped with no way to scroll to reach it — the maintainer's exact objection. The two-regime wrapper supersedes it.
• Nested-template /template/ ScrollViewer#PART_ScrollViewer: the inner ScrollViewer is unnamed in Avalonia 12.1, so #PART_ScrollViewer matches nothing. (Note: the ancestor lookup $parent[ScrollViewer] still resolves it by type — that is what the wrapper uses.)
• Full ControlTemplate replacement: unnecessary and costly; the attached-property + ItemsPanel wrapper already achieves correct wrapping, minimum-respecting scroll, and vertical scroll.
• Per-item MaxWidth → Viewport.Width: rejected (fights indentation); the single wrapper handles indentation normally inside it (see entity-card-tree-view: entity cards expand far beyond the viewport horizontally; must be capped to viewport width (follow-up to #1045) #1049).

One scroller, not two

The consolidated style means the tree's own inner scroller is the single scroller. The nested outer + inner arrangement in MainWindow.axaml and EntityBrowserWorkspaceTabView.axaml is the anti-pattern: the outer Disabled scroller cannot cap the inner scroller's measure, and it also cannot provide the below-minimum horizontal scrollbar the wrapper now supplies. Once the class is applied, the outer scrollers are removable.

Experimental Evidence

Headless Avalonia 12.1 (Avalonia.Headless + Avalonia.Headless.XUnit), project C:\dev\test\Avalonia\WrapExperiment (TwoRegimeExperiments.cs, plus the retained StyleOnlyExperiments.cs baseline). A bare TreeView with NO surrounding ScrollViewer, only the candidate class + consolidated two-regime style applied, rendering a git-worktree card whose path is the 154-char worktree path from the screenshot. Each row is measured/arranged at the given client size, then Bounds/Extent/Viewport and the inner scroller's props are asserted. Full suite: 43/43 pass.

Two regimes (standard card, fixed 200,* label column)

Two regimes (softened Auto,* label column — value column no longer starved)

Vertical scroll, gutter, and scroll-reach

Which viewport-width binding resolved

Key asserted numbers: regime 1 wrapper/extent collapse to exactly the viewport (800→800), path wraps; regime 2 wrapper clamps to MinWidth=160 > viewport, Extent.W=160, a horizontal scrollbar appears and content is reachable; vertical Extent.H=3420 > 300 with a 16px gutter; binding proof wrapper MaxWidth == inner Viewport.Width = 784.

Locked-in passing tests (TwoRegimeExperiments): TwoRegime_SV_AttachedProperty_FlowsToInnerScrollViewer, TwoRegime_SV_WideViewport_CapsToViewport_Wraps_NoHScroll, TwoRegime_SV_NarrowViewport_ShowsHScrollbar_WrapsAtMin, TwoRegime_SV_NarrowViewport_CanScrollToRevealMinContent, TwoRegime_SV_NestedItem_WrapsWithinWrapper, TwoRegime_SV_ManyItems_VerticalScrollIntact_NoHScroll, TwoRegime_SV_SoftLabel_NarrowViewport_WrapsAtMin_AndScrolls, TwoRegime_SV_SoftLabel_WideViewport_CapsAndWraps_NoHScroll, TwoRegime_SV_WrapperMaxWidth_ResolvesToInnerViewport, plus candidate-B comparators TwoRegime_TV_WideViewport_CapsToTreeBounds_Wraps_NoHScroll, TwoRegime_TV_NarrowViewport_ShowsHScrollbar, TwoRegime_TV_ManyItems_RecordResolvedWidths. The StyleOnlyExperiments.* and ViewRendererExperiments.* tests remain green.

Remediation Inventory

Surrounding ScrollViewers to remove

Count: 2 surrounding ScrollViewers should be removed. (Unchanged from the previous round; the change is that the class now carries the two-regime wrapper, not just H=Disabled.)

TreeViews to restyle

Count: 2 TreeViews (both fixed by the single base rule + outer-scroller removal).

Keep as-is / already correct

• Phantom.Workspaces.Agent.Gui/Controls/AgentChatToolsDetailControl.axaml:16-21 — legacy entity-card-tree, no surrounding ScrollViewer; currently sets H=Disabled inline. Once the two-regime base rule lands, its inline ScrollViewer.* setters are superseded and should be removed so it inherits the two-regime behavior (otherwise the inline H=Disabled would keep it clip-only in the narrow regime). This is a behavior improvement (it gains the below-minimum scrollbar), not just cleanup.
• Phantom.Workspaces.Agent.Gui/Controls/AgentChatEditorControl.axaml:251 — entity-card-tree-view (entity-card-tree-view: entity cards expand far beyond the viewport horizontally; must be capped to viewport width (follow-up to #1045) #1049's wrapper). Same pattern View renderer (views/*): git-worktree entity cards overflow horizontally / path field does not wrap (MainWindow entity-pane, legacy entity-card-tree inner ScrollViewer) #1064 now adopts. If the shared base style is used, this is backed by the same rule; leave the consumer unchanged.

Affected Files

Expected Tests

Naming Subject_Scenario_ExpectedOutcome, matching Phantom.Workspaces.Gui.Shared.Tests/SharedStylesTests.cs ([PhantomAvaloniaFact] layout tests + string-AXAML assertions) and Phantom.Workspaces.Agent.Gui.Tests/MainWindowAxamlTests.cs. The headless assertions below already pass in the experiment project (TwoRegimeExperiments.cs) and should be ported.

Where a value is purely visual (exact gutter pixels), assert the style/attached-property value and the measured/arranged widths as above.

Considered / Background

• Disabled-only consolidated style (previous round — rejected/insufficient): setting TreeView.entity-card-tree to ScrollViewer.HorizontalScrollBarVisibility="Disabled" wraps content but removes horizontal scrolling entirely, so when the viewport is narrower than the card's hard minimum widths the card is clipped with no scrollbar to reach it. This is the maintainer's objection and the reason this body switches to the entity-card-tree-view: entity cards expand far beyond the viewport horizontally; must be capped to viewport width (follow-up to #1045) #1049 two-regime wrapper. (Empirical: Disabled capped card == viewport at 800/400 and wrapped, but had no mechanism to scroll below the ~160 minimum.)
• Nested-template selector /template/ ScrollViewer#PART_ScrollViewer: rejected — the inner ScrollViewer is unnamed in the Avalonia 12.1 TreeView template, so #PART_ScrollViewer matches nothing. (The ancestor lookup $parent[ScrollViewer] in the wrapper still resolves it by type.)
• Full ControlTemplate replacement: rejected — duplicates the Fluent template for no benefit; the attached-property + ItemsPanel wrapper is sufficient.
• $parent[TreeView].Bounds.Width viewport source: resolves but rejected — includes the vertical-scrollbar gutter (800 vs the correct 784) and relies on Stretch re-capping; the $parent[ScrollViewer].Viewport.Width source is gutter-correct and matches entity-card-tree-view: entity cards expand far beyond the viewport horizontally; must be capped to viewport width (follow-up to #1045) #1049.
• Superseded (incorrect) explanation: the original body attributed this overflow to the Entity Browser. The screenshot is actually a saved View (views/git-workspaces) rendered by the MainWindow.axaml entity-pane TreeView. The mechanism (legacy entity-card-tree + inner Auto scroller defeating wrap) is the same, and the Entity Browser shares the identical latent defect, but the reported control is the View renderer.
• Superseded (targeted-only) fix: View renderer (views/*): git-worktree entity cards overflow horizontally / path field does not wrap (MainWindow entity-pane, legacy entity-card-tree inner ScrollViewer) #1064 previously recommended an inline H=Disabled on the MainWindow.axaml tree inside its outer ScrollViewer. The consolidated two-regime style is better: the outer scroller is unnecessary and a single class rule fixes every legacy consumer with correct below-minimum scrolling.
• Relationship to entity-card-tree-view: entity cards expand far beyond the viewport horizontally; must be capped to viewport width (follow-up to #1045) #1049: View renderer (views/*): git-worktree entity cards overflow horizontally / path field does not wrap (MainWindow entity-pane, legacy entity-card-tree inner ScrollViewer) #1064 now uses the same MinWidth=160 + viewport-MaxWidth + Auto wrapper pattern as entity-card-tree-view: entity cards expand far beyond the viewport horizontally; must be capped to viewport width (follow-up to #1045) #1049's entity-card-tree-view. A shared base style backing both classes is recommended (see Design / Fix). entity-card-tree-view: entity cards expand far beyond the viewport horizontally; must be capped to viewport width (follow-up to #1045) #1049 remains correct and, if consolidated, is backed by the same rule.
• Why not just TextWrapping="Wrap"? It is already Wrap (workspace-field-read-value); wrapping is inert until the measure is finite, which the viewport-MaxWidth supplies.