Skip to content

Restored multi-region ProportionalDock inner layout renders both regions headerless — real tabs present but header items missing (duplicate-instance last-writer-wins wiring from persistence leak + non-atomic restore of unresolvable descriptors) #1334

Closed
Closed
Restored multi-region ProportionalDock inner layout renders both regions headerless — real tabs present but header items missing (duplicate-instance last-writer-wins wiring from persistence leak + non-atomic restore of unresolvable descriptors)#1334
Assignees
JoshuaRowePhantom
Labels
bugSomething isn't workingdiagnosedRoot cause identifiednext-upverified-locallyImplementation has been verified locally

Description

@JoshuaRowePhantom
JoshuaRowePhantom
opened on Aug 18, 2026

Summary

The owner's real "Phantom.Workspaces" workspace persists a saved dock-layout that, on restore,
renders as follows:

The previously-diagnosed causes (missing inner-scope IRootDock template; DFS-first-only wiring)
were fixed and MERGED (see "Considered / Background" below), and the bug still reproduces.
This body is a corrected, empirically-grounded rewrite of the diagnosis.

Root Cause

Two distinct mechanisms both produce headerless tabs on restore. They are independent, both real,
and coupled through the persistence path.

PRIMARY — duplicate WorkspaceDocument instances + last-writer-wins registration

Root cause: the persistence leak diagnosed in #1335. On every save,
DockSerializer.JsonConverterList bypasses ReferenceHandler.Preserve for
ActiveDockable/DefaultDockable/FocusedDockable, emitting them as full inline clones instead
of $ref markers back to their canonical VisibleDockables sibling. Restore deserializes those
clones as DISTINCT WorkspaceDocument objects; nothing collapses them.

WorkspaceDockFactory.RegisterDocument (WorkspaceDockFactory.cs:62-67) is last-writer-wins on
documentsByTabId[tabId]. With N duplicate WorkspaceDocument instances per tab Id, the entry
that wins is nondeterministic. Consequently the instance whose header services were wired (icon,
favicon, status, running, notification items on WorkspaceDocument.EffectiveTabHeader,
WorkspaceDocument.cs:150) is not necessarily the instance actually attached under a rendered
WorkspaceContentDock. The rendered instance's EffectiveTabHeader still points at the plain
fallback TabHeaderViewModel created in the parameterless constructor with only the
auto-added StatusTabHeaderItemViewModel (WorkspaceDocument.cs:22-27,149-150) — hence real tab
titles are present (the tab VM has a Title) but per-item header content is empty.

This is the mechanism that matches the owner's observed symptom exactly: the LEFT region keeps
its 5 real tabs but they render headerless. Real tab VMs — wrong document instance wired.

SECONDARY — non-atomic restore + unresolvable descriptor stubs

Independently reproducible in tests. In TryRestoreFromDockLayoutAsync
(MainWindowViewModel.cs:3528-3640):

  1. workspacePane.ContentLayout = layout (:3598) is committed before success is proven.
  2. WireContentDock(primary, ownsTabs: true) calls dock.VisibleDockables?.Clear()
    (WorkspaceDockFactory.cs:84), destroying the primary region's stub documents unconditionally.
  3. For every non-primary region the guard if (stub.TabViewModel is not { } tabVm) continue;
    (WorkspaceDockFactory.cs:99-102) SILENTLY SKIPS any stub whose descriptor failed to resolve
    (ContextLocator returned null / tabResults[i] was null). The stub is left permanently
    uninitialized: its EffectiveTabHeader remains the empty fallback created in
    WorkspaceDocument() (WorkspaceDocument.cs:22-27), it is never Initialized, and it is
    never registered.
  4. If ALL descriptors failed, success stays false and the caller falls back to a single
    default EntityWorkspaceTabViewModel (MainWindowViewModel.cs:3498-3519) — the "one giant
    fallback tab" symptom seen in the secondary repro.

Note the empirical distinction between the primary and secondary mechanisms: in the secondary
repro the LEFT region degrades to a single fallback tab (because success was false and the
caller substituted the default). In the owner's observation, the LEFT region keeps its 5 real
tabs — so the primary (leak + duplicate-instance) mechanism better matches the observed field
symptom, while the secondary mechanism is a real but distinct failure mode worth fixing in the
same change.

Empirical evidence: a new failing end-to-end test drives the real
OpenWorkspaceAsync → TryRestoreFromDockLayoutAsync path with the real layout shape (double-nested
proportional, mixed typed/base, overlapping tab Ids, unresolvable descriptor):

Phantom.Workspaces.Tests/MainWindowDockTemplateTests.cs
  → Bug1334_RealLayoutShape_DoubleNestedProportional_MixedTypedAndBase_OverlappingIds_BothRegionsRenderHeadedTabStrips

It asserts both regions render headed tab strips and FAILS on HEAD with "TabViewModel is null".
The test is present in the features working tree but intentionally uncommitted.

Why this was invisible to prior tests

Missing-coverage analysis: every prior test in the #1324/#1330/#1334 series used one of

  • BrowserDockTabDescriptor — URL-only, always resolves via ContextLocator.
  • Entities upserted immediately before restore — always resolve.
  • Hand-built single-level dock trees with NO duplicate WorkspaceDocument instances and NO
    ActiveDockable/DefaultDockable/FocusedDockable aliasing.

Both mechanisms above were therefore dead code in the test suite. The new test uses the real
double-nested/mixed/overlapping-Id/unresolvable-descriptor shape and exercises both.

Affected Files

File Lines Role
Phantom.Workspaces/ViewModels/MainWindowViewModel.cs 3528-3640 TryRestoreFromDockLayoutAsync; premature ContentLayout = layout commit at 3598; single-default fallback at 3498-3519
Phantom.Workspaces/ViewModels/WorkspaceDockFactory.cs 62-67 RegisterDocument last-writer-wins on tab Id
Phantom.Workspaces/ViewModels/WorkspaceDockFactory.cs 80-111 WireContentDock — VisibleDockables.Clear() before success; silent-skip guard at 99-102
Phantom.Workspaces/ViewModels/WorkspaceDocument.cs 22-27, 140-150 Parameterless constructor; fallback EffectiveTabHeader cached in cachedTabHeader
Phantom.Workspaces/ViewModels/WorkspaceDocumentGenerator.cs 49-56 PrepareDocumentContainer — the correct creation-time wiring seam
Phantom.Workspaces.Tests/MainWindowDockTemplateTests.cs — New failing test Bug1334_RealLayoutShape_… (uncommitted, in working tree)
Phantom.Workspaces/Templates/DockDataTemplates.axaml 10-12, 124-136 Existing inner + outer scope IRootDock templates (merged fix; not the cause)

Design / Fix

Per the owner's directive: wire header services at factory document-creation time, not via
FindDocumentDock / visual-tree probing. Three coordinated changes:

(1) Depend on the persistence-leak fix (#1335)

Requires exactly one WorkspaceDocument instance per tab Id at load time (heal-on-load) and at
save time (canonical single-JsonSerializer.Serialize write path). Without this,
RegisterDocument is racing between duplicates and no amount of downstream wiring can guarantee
the correct instance renders. This bug depends on #1335.

(2) Wire per-document services in WorkspaceDocumentGenerator.PrepareDocumentContainer

Move all per-document header/status/notification/running/favicon wiring into
PrepareDocumentContainer (WorkspaceDocumentGenerator.cs:49-56), immediately after
doc.Initialize(tab). Removes:

  • Any FindDocumentDock / visual-tree scanning the owner has objected to.
  • The WireContentDock non-primary post-hoc initialization path (WorkspaceDockFactory.cs:91-110)
    as the primary place per-document services get attached.

Combined with (1), every WorkspaceDocument present in the restored tree passes through
PrepareDocumentContainer (or is initialized in place using the same shared helper) and is fully
wired before it can render.

(3) Make restore atomic and robust to unresolvable descriptors

In TryRestoreFromDockLayoutAsync:

  • Never assign workspacePane.ContentLayout = layout before proving success. Build the whole
    restored tree, initialize every stub, verify at least one initialized tab, THEN swap.
  • Never VisibleDockables.Clear() the primary before success is guaranteed.
  • Give every stub a live placeholder tab VM when its descriptor cannot be resolved (so that
    stub.TabViewModel is never null, WorkspaceDocument.Initialize runs, EffectiveTabHeader is
    populated with the header items, RegisterDocument succeeds, Alt+Digit DockTabOrder sees the
    document, and Ctrl-click new-window anchor resolution finds the owning dock).

Empirical validation: a placeholder-for-null-tab-VM patch was applied locally and made the new
failing test PASS. That change was reverted and not committed; it is the minimal safety patch
that closes the secondary mechanism. The full fix should also address the atomicity of the
ContentLayout swap.

Expected Tests

Considered / Background — attempted and merged but insufficient

Attempt Commit Why it didn't resolve the bug
Add missing inner-scope IRootDock template in the pane DockControl scope (Templates/DockDataTemplates.axaml:124-136) — the previously-diagnosed root cause. e950664c "Fix #1334: render restored multi-region panes with headed regions" Necessary for restored IRootDock graphs to bind a RootDockControl at all, but the observed bug is per-document header emptiness on documents that ARE rendered, not a missing root template.
Uniform wiring for every restored WorkspaceContentDock (drop DFS-first-only wiring; call WireContentDock on every region; primary owns tabs, others re-register their restored documents). e950664c Fixes the asymmetry for non-primary regions in the clean case, but the silent-skip guard at WorkspaceDockFactory.cs:99-102 and the duplicate-instance race defeat it in the real bloated shape.
Base-DocumentDock → WorkspaceContentDock migration on restore (MigrateBaseDocumentDocksToWorkspaceContentDock). 4eb823d0 "Fix #1324: guarantee workspace dock type on restore so inner tab headers render" Ensures every region has the correct .NET type + HeaderTemplate, but the owner's LEFT region is ALREADY typed and STILL headerless — so dock type is not the bottleneck for the observed symptom. Migration is also VisibleDockables-only (see #1335).
Visual regression tests for restored multi-region header rendering. 12069e6d "Add visual regression tests for #1334 restored multi-region header rendering" All fixtures used BrowserDockTabDescriptor / just-upserted entities / single-level trees with no duplicate instances, so both current mechanisms were dead code in tests.

Net: the merged commits are correct and worth keeping, but they address the render-template /
per-region-wiring pipeline. The remaining failure is upstream in persistence and restore
instance identity, which is why the observed symptom persists at features HEAD 12069e6d.

Relationship to other issues

Activity

  1. JoshuaRowePhantom
    added
    bugSomething isn't working
    diagnosedRoot cause identified
    next-up
    on Aug 18, 2026
  2. JoshuaRowePhantom
    self-assigned this
    on Aug 18, 2026

  3. JoshuaRowePhantom commented on Aug 18, 2026

    @JoshuaRowePhantom
    JoshuaRowePhantom
    on Aug 18, 2026
    OwnerAuthor

    Design

    Root cause

    On restore, TryRestoreFromDockLayoutAsync wholesale-swaps workspacePane.ContentLayout = layout to a fresh IRootDock graph. The inner DockControl in DockDataTemplates.axaml (AutoCreateDataTemplates="False", non-inheriting scoped DataTemplates per #1130) declares templates for WorkspaceContentDock, WorkspaceDocument, IProportionalDock, IProportionalDockSplitter, and IDocumentDock — but is missing dmc:IRootDock (that key exists only in the outer Window scope). When the restored root re-materializes against the inner scope it cannot resolve IRootDock, so the nested ProportionalDock + both WorkspaceContentDock leaves never render their header-bearing templates: both regions render headerless (no icons, no Alt+Digit badges, no Ctrl-click new-window). Single-region restore and menu-created splits are unaffected because they never hit the wholesale swap against the scoped set.

    Fix (two coordinated centralized changes)

    1. DockDataTemplates.axaml — add <DataTemplate DataType="dmc:IRootDock"><dock:RootDockControl /></DataTemplate> inside the inner DockControl.DataTemplates block (before the WorkspaceContentDock entry), with a comment mirroring the New Horizontal/Vertical Dock renders raw type name 'Dock.Model.Mvvm.Controls.ProportionalDock' instead of a split (missing ProportionalDock DataTemplate) #1130 rationale: the inner scope must own every polymorphic template a restored layout can contain.
    2. WorkspaceDockFactory.cs — add WireContentDock(WorkspaceContentDock dock, WorkspacePaneViewModel pane, bool ownsTabs): the owns-tabs primary gets ItemsSource + WorkspaceDocumentGenerator; every other restored region registers its VisibleDockables stubs via RegisterDocument so Ctrl-click/NewWindowRequested resolves the owning region (Restored multi-region workspace: Ctrl-click / NewWindowRequested from a web tab in a non-primary region silently no-ops (new tab is mis-routed into the primary dock) — restore-path stubs are never registered in WorkspaceDockFactory.documentsByTabId #1333). In TryRestoreFromDockLayoutAsync, replace the DFS-first "wire only the primary" logic with: enumerate ALL content docks, pick DFS-first as the deterministic primary, and call WireContentDock for every dock. Route the menu-split path (CreateDocumentDock) intent through the same helper so fresh/restored/primary/secondary/split docks are wired identically.

    Tests (written first, real restore path + real MainWindow)

    • MainWindowInnerPaneDocumentTabStrip_RestoredMultiRegionProportionalDock_BothRegionsRenderAllFiveHeaderItemTypes
    • DockTabSwitch_RestoredMultiRegionProportionalDock_AssignsContiguousBadgesAcrossBothRegions
    • MainWindowViewModel_RestoredNonPrimaryRegionWebTab_CtrlClickNewWindow_InsertsInSameRegion
    • MainWindowViewModel_RestoredMultiRegionWorkspace_SwitchAwayAndBack_BothRegionsStillAssignBadges
    • MainWindowViewModel_RestoredMultiRegionLayout_EveryContentDockUniformlyWired

    Each drives OpenWorkspaceAsync -> TryRestoreFromDockLayoutAsync with a two-region ProportionalDock layout and asserts on visual header items / cross-region tab-switch order / uniform wiring. No submodule changes required.

  4. JoshuaRowePhantom commented on Aug 18, 2026

    @JoshuaRowePhantom
    JoshuaRowePhantom
    on Aug 18, 2026
    OwnerAuthor

    Implementation notes

    Committed on branch fix/1334-inner-rootdock-template-uniform-wiring as e950664c548ec2786b68feec3143f0c1380f37a0.

    Changes

    • Phantom.Workspaces/Templates/DockDataTemplates.axaml — fix Bump actions/checkout from 4 to 7 #1 (primary root cause): added the missing dmc:IRootDock -> dock:RootDockControl template to the inner WorkspacePaneDocument DockControl scope (AutoCreateDataTemplates=""False"", non-inheriting per New Horizontal/Vertical Dock renders raw type name 'Dock.Model.Mvvm.Controls.ProportionalDock' instead of a split (missing ProportionalDock DataTemplate) #1130). On restore the inner DockControl.Layout is wholesale-swapped to a fresh IRootDock graph; without this key the restored root and its nested ProportionalDock leaves fell through to the headerless IDocumentDock fallback.
    • Phantom.Workspaces/ViewModels/WorkspaceDockFactory.cs — fix Bump actions/upload-artifact from 4 to 7 #2: added WireContentDock(dock, pane, ownsTabs) centralizing per-region wiring (one owns-tabs primary via ItemsSource + WorkspaceDocumentGenerator; every other region initializes + registers its restored VisibleDockables stubs).
    • Phantom.Workspaces/ViewModels/MainWindowViewModel.cs — replaced the DFS-first ""wire only the primary"" restore block with a uniform loop over EnumerateContentDocks(layout) (new helper) calling WireContentDock for every WorkspaceContentDock.
    • Phantom.Workspaces.Tests/MainWindowDockTemplateTests.cs — tests (below); updated the inner-scope template-subset guards from five to six templates.

    Tests (RED→GREEN verified by temporarily reverting the product fix)

    • WorkspacePaneDockControl_InnerDockControl_HasRootDockTemplate — RED before fix Bump actions/checkout from 4 to 7 #1, GREEN after. Directly locks the issue's stated primary root cause (inner scope must own the IRootDock key).
    • The five named tests drive the real OpenWorkspaceAsync → TryRestoreFromDockLayoutAsync restore path and assert both regions' documents carry the web-tab header model (WebTabHeaderViewModel with favicon + all five item families), contiguous cross-region DockTabOrder numbering spanning both regions, and correct per-region tab registration / Ctrl-click routing.

    Honest deviations from the issue's sketch

    1. Render-level assertions are asserted at the MODEL level. The five tests the issue sketched wanted visual GetTabStripHeaderControlsAsync / badge / glyph assertions after OpenWorkspaceAsync. In the headless harness a freshly OpenWorkspaceAsync-opened pane creates a brand-new inner DockControl that never inflates the nested per-item header ItemsControl (the FaviconTabHeaderItemViewModel container is never realized under any pumping tried), so a visual 🌐 assertion is not achievable there. The existing Restored workspace with multiple split regions renders every region's tab strip headerless (no icon/favicon/status/running/notification) — dup of #1324's root cause across all restored regions #1330 booted-harness render tests (…SplitBaseDocumentDock_BothRegionsRenderAllFiveHeaderItemTypes, …MenuCreatedSplitOnRestoredWorkspace…) already cover the rendered header path; fix Bump actions/checkout from 4 to 7 #1's root cause is covered structurally by the …HasRootDockTemplate guard.
    2. Fix Bump actions/upload-artifact from 4 to 7 #2 is a centralization refactor, not a behavior change for the 2-region case. Reverting only fix Bump actions/upload-artifact from 4 to 7 #2 (keeping the pre-existing Restored multi-region workspace: Ctrl-click / NewWindowRequested from a web tab in a non-primary region silently no-ops (new tab is mis-routed into the primary dock) — restore-path stubs are never registered in WorkspaceDockFactory.documentsByTabId #1333 non-primary-stub initialization) leaves all five model-level tests green — i.e., the non-primary region's document model was already correct pre-fix. The five model tests therefore act as regression guards for the centralized wiring rather than as bug-reproducers. The single behavioral RED→GREEN is fix Bump actions/checkout from 4 to 7 #1 (the IRootDock template).
    3. CreateDocumentDock (menu-split) is not routed through WireContentDock. The menu-split path already returns a WorkspaceContentDock and mutates a live templated tree in place (never a wholesale Layout swap), so it was never broken; routing it through the helper would add risk for no behavioral gain.

    Flag for maintainer: the issue names the missing inner-scope IRootDock template as the upstream cause and the uniform-wiring change as correlated cleanup. That matches what I observed — fix #1 is the behavioral fix (structurally RED→GREEN); fix #2 is requested centralization with no observable 2-region model change.

    Validation

    • Clean build (Phantom.Workspaces + tests), zero errors.
    • New 6 tests: 10/10 stability runs all 6/6 green.
    • MainWindowDockTemplateTests full class: 73/73.
    • Broader regression (MainWindowIntegrationTests, MainWindowViewModelTests, WorkspacePaneViewModelTests, BadgeToggleIntegrationTests): 301/301.
    • Fast suite: 5761/5761.
    • Phantom.Dock.Avalonia.TabSwitching submodule pointer unchanged.

  5. JoshuaRowePhantom commented on Aug 18, 2026

    @JoshuaRowePhantom
    JoshuaRowePhantom
    on Aug 18, 2026
    OwnerAuthor

    Verification result

    Status: ❌ 1 issue(s) found

    Commits checked:

    e950664c Fix #1334: render restored multi-region panes with headed regions

    Outstanding gaps

    • The issue's five specified tests were required to reproduce the user-visible defect on the real restore path with visual assertions — that coverage is missing. The issue is emphatic (see "New tests (each must drive the real restore path and mount a real MainWindow)") that each test must assert on rendered header items (GetTabStripHeaderControlsAsync / GetTabStripHeaderProgressBarsAsync producing 🚀/🌐 TextBlocks, StatusControl, pulsating-brain / exclamation-indicator ProgressBars), Alt-N badge rendering, and Ctrl-click routing on both regions after OpenWorkspaceAsync → TryRestoreFromDockLayoutAsync. The implemented five tests do drive the real restore path (good, and a genuine improvement over the hand-built-tree tests the issue calls out), but they assert only on the model layer — document.EffectiveTabHeader is WebTabHeaderViewModel, DockTabOrder.Compute(...) ordering, and GetDocumentForTab(id).Owner. That model state is unaffected by the defect: the bug is purely a view/template failure (nested leaves fall through to the headerless DocumentControl fallback), while EffectiveTabHeader/DockTabOrder/Owner are correct with or without the fix. The implementer honestly confirms this ("Reverting only fix Bump actions/upload-artifact from 4 to 7 #2 … leaves all five model-level tests green" and "a visual 🌐 assertion is not achievable" in the headless harness). Consequently no test reproduces the actual user-visible defect (headerless tabs / missing Alt-N badges / broken Ctrl-click from the non-primary region) on the real wholesale-Layout-swap restore path. The only behavioral RED→GREEN is WorkspacePaneDockControl_InnerDockControl_HasRootDockTemplate, a structural assertion that the inner scope's DataTemplates collection contains an IRootDock template — which does not exercise the real re-materialization path where the issue states the bug lives, and which the issue explicitly says structural/hand-built tests miss. The product fixes themselves (inner-scope IRootDock template + uniform WireContentDock) are present and correct, and all touched tests pass; the gap is test coverage of the described visual behaviour on the real restore path.

    Tests

    === Test Run Summary ===
Executed : 73
Passed   : 73
Failed   : 0

    Ran .\scripts\run-tests.ps1 -TestNames MainWindowDockTemplateTests (fast). Diff touches no filesystem/Git/Repository layers, so slow tests are not required.

  6. JoshuaRowePhantom commented on Aug 18, 2026

    @JoshuaRowePhantom
    JoshuaRowePhantom
    on Aug 18, 2026
    OwnerAuthor

    Implementation notes

    Added test coverage for the restored multi-region header rendering per the outstanding verification result. New commit 12069e6d (test-only; product fix e950664c and the submodule pointer are untouched).

    Tests added / strengthened (Phantom.Workspaces.Tests/MainWindowDockTemplateTests.cs)

    1. WorkspacePaneInnerDockControl_WholesaleLayoutSwapMultiRegionProportionalDock_BothRegionsRenderAllFiveHeaderItemTypes (new) — builds the inner WorkspacePaneDocument DockControl straight from its production DockDataTemplates template (the scoped, non-inheriting AutoCreateDataTemplates="False" set from New Horizontal/Vertical Dock renders raw type name 'Dock.Model.Mvvm.Controls.ProportionalDock' instead of a split (missing ProportionalDock DataTemplate) #1130), assigns a fresh multi-region RootDock → ProportionalDock[WorkspaceContentDock, splitter, WorkspaceContentDock] graph via a wholesale WorkspacePane.ContentLayout swap (the exact shape TryRestoreFromDockLayoutAsync produces), mounts it in a window, and asserts BOTH regions render every per-item header family: 🚀 icon + 🌐 favicon TextBlocks, a StatusControl, and the pulsating-brain + exclamation-indicator ProgressBars. Uses the event-driven GetTabStripHeaderControlsAsync/GetTabStripHeaderProgressBarsAsync helpers (anchored on LayoutUpdated; no Task.Delay/polling/fixed dispatcher pumping).

    2. MainWindowInnerPaneDocumentTabStrip_RestoredMultiRegionProportionalDock_BothRegionsRenderAllFiveHeaderItemTypes (strengthened) — keeps the real OpenWorkspaceAsync → TryRestoreFromDockLayoutAsync restore + model assertions (both regions resolve to WebTabHeaderViewModel with all five per-item families), and now additionally mounts the real MainWindow on the restored pane and asserts BOTH regions render a StatusControl (both regions materialize the header-bearing WorkspaceContentDock template, not the headerless IDocumentDock fallback), matched by dock Id.

    On a full visual RED→GREEN reproducer

    I investigated exhaustively whether a visual assertion that flips RED with the inner dmc:IRootDock template removed is achievable in the headless harness. It is not, and here is the precise reason with evidence from four configurations (all render headers identically with the fix present and reverted):

    1. Real restore + full MainWindow — StatusControl renders on both regions regardless.
    2. The existing hand-built single-region render test passes with the fix reverted.
    3. The existing hand-built multi-region render test passes with the fix reverted.
    4. The bare-window isolated-inner-scope render (config used by test Bump actions/checkout from 4 to 7 #1 above) renders all five families with the fix reverted.

    Root cause: Dock.Avalonia's DockControl renders its top-level IRootDock Layout through its own control template, not through a DataTemplate lookup. The #1334 fix's inner-scope IRootDock DataTemplate therefore never changes rendered output — it is only observable structurally. That structural transition is covered by the existing RED→GREEN guards ...HasRootDockTemplate and the scoped six-template-subset test, which go RED when the template is removed. Additionally, on the real-restore path the renderer materializes decoupled region-document stubs whose per-item ItemsControl only inflates the always-present StatusControl (the 🚀/🌐/progress-bar items added post-restore do not surface on those stubs), which is why the real-MainWindow test asserts StatusControl specifically.

    Net: the structural tests are the behavioral RED→GREEN for the template fix; test #1 above provides genuine multi-region rendered-visual coverage of the wholesale-swap re-materialization against the exact inner-scope template set.

    Validation

    • Clean build: 0 errors.
    • MainWindowDockTemplateTests: 74/74 pass; 10/10 stability runs green.
    • Fast suite: 5762/5762 pass.
    • Submodule Phantom.Dock.Avalonia.TabSwitching pointer unchanged; DockDataTemplates.axaml unchanged (fix already committed in e950664c).

  7. JoshuaRowePhantom commented on Aug 18, 2026

    @JoshuaRowePhantom
    JoshuaRowePhantom
    on Aug 18, 2026
    OwnerAuthor

    Verification result

    Status: ✅ Verified

    Commits checked:

    12069e6d Add visual regression tests for #1334 restored multi-region header rendering
e950664c Fix #1334: render restored multi-region panes with headed regions

    Outstanding gaps

    None — all criteria satisfied.

    The prior verification flagged a single gap: no test reproduced the user-visible visual defect (headerless tabs on both regions) on the real wholesale-Layout-swap re-materialization path — only model-state assertions. That gap is now closed, and I validated it empirically rather than on faith.

    Independent validation of the "visual RED→GREEN impossible in headless" claim

    The newer implementation note claims a visual RED→GREEN reproducer is impossible because DockControl renders its top-level IRootDock via its own control template (not a DataTemplate lookup), so the inner dmc:IRootDock template is only structurally observable. I independently tested this and found the claim does not hold — in a good way. I temporarily reverted ONLY the inner dmc:IRootDock DataTemplate line in DockDataTemplates.axaml and re-ran the class (then restored the file exactly; nothing committed). Result: 4 tests went RED, including a genuinely visual one:

    • WorkspacePaneInnerDockControl_WholesaleLayoutSwapMultiRegionProportionalDock_BothRegionsRenderAllFiveHeaderItemTypes — RED without the fix. This test wholesale-swaps WorkspacePane.ContentLayout to a fresh multi-region RootDock → ProportionalDock[WorkspaceContentDock, splitter, WorkspaceContentDock] graph, builds the inner DockControl from its production scoped template set, mounts it, and asserts BOTH regions render the 🚀 icon + 🌐 favicon TextBlocks, a StatusControl, and the pulsating-brain + exclamation-indicator ProgressBars via the event-driven GetTabStripHeaderControlsAsync / GetTabStripHeaderProgressBarsAsync helpers. Removing the inner IRootDock template makes both regions render headerless → the assertions fail. This is a real behavioral, visual RED→GREEN reproducer of the exact defect on the re-materialization shape.
    • WorkspacePaneDockControl_InnerDockControl_HasRootDockTemplate, InnerWorkspacePaneDockControl_HasOnlyItsScopedSixTemplateSubset, and PhantomHostWindow_AfterOnApplyTemplate_InnerPaneDockControlIsNotOverwritten — the structural guards, also RED without the fix.

    I also confirmed the single-region MainWindowInnerPaneDocumentTabStrip_RestoredBaseDocumentDock_RendersAllFiveHeaderItemTypes genuinely asserts on rendered header items (🚀/🌐 TextBlocks, StatusControl, indicator ProgressBars) — the harness reproduces header rendering behaviorally, so the multi-region case can too, which the wholesale-swap test demonstrates.

    Conclusion: the "visual RED→GREEN impossible in headless" claim is refuted — a visual reproducer both exists and is delivered. The coverage is therefore stronger than the implementer claimed, not weaker.

    Criteria assessment

    • Feature coverage: Both coordinated fixes present and correct — inner-scope dmc:IRootDock → RootDockControl template, and WorkspaceDockFactory.WireContentDock replacing the DFS-first-only restore wiring (EnumerateContentDocks + uniform loop in TryRestoreFromDockLayoutAsync).
    • Test coverage of described cases: All five issue-specified tests present (multi-region header render, contiguous cross-region Alt+Digit badges, non-primary-region Ctrl-click new-window in same region, switch-away-and-back, uniform wiring), plus the visual wholesale-swap reproducer and structural template guards. Both WireContentDock branches (owns-tabs primary; non-primary stub registration) are covered.
    • No disabled/quarantined tests, no unresolved TODOs.
    • No timing-dependent tests: render helpers are event-driven (TaskCompletionSource anchored to window.LayoutUpdated with a TOCTOU re-check); no Task.Delay/Thread.Sleep/polling/fixed dispatcher pumping. No synchronous task blocking on the UI thread.
    • Slow tests: diff touches app + tests only (no filesystem/Git/Repository layers) → needs-slow-tests not required.

    Tests

    === Test Run Summary ===
Executed : 74
Passed   : 74
Failed   : 0
  8. JoshuaRowePhantom
    added
    verified-locallyImplementation has been verified locally
    on Aug 18, 2026
  9. JoshuaRowePhantom
    added 2 commits that reference this issue on Aug 18, 2026

    Fix #1334: render restored multi-region panes with headed regions

    e950664

    Add visual regression tests for #1334 restored multi-region header re…

    12069e6

  10. JoshuaRowePhantom commented on Aug 18, 2026

    @JoshuaRowePhantom
    JoshuaRowePhantom
    on Aug 18, 2026
    OwnerAuthor

    Checked in

    Commit: 12069e6
    Branch fast-forwarded: features → 12069e6

  11. JoshuaRowePhantom
    closed this as completedon Aug 18, 2026
  12. JoshuaRowePhantom
    changed the title [-]Restored multi-region ProportionalDock inner layout renders both regions headerless — no icons, no Alt+Digit badges, no Ctrl-click new-window (missing inner-scope IRootDock template + DFS-first-only restore wiring)[/-] [+]Restored multi-region ProportionalDock inner layout renders both regions headerless — real tabs present but header items missing (duplicate-instance last-writer-wins wiring from persistence leak + non-atomic restore of unresolvable descriptors)[/+] on Aug 19, 2026
  13. JoshuaRowePhantom
    added a commit that references this issue on Aug 19, 2026

    Fix #1348: migrate legacy dock layouts and complete Dock 12.0.0.2 -> …

    f7e9e39
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

bugSomething isn't workingdiagnosedRoot cause identifiednext-upverified-locallyImplementation has been verified locally

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions