Problem / Why
The EfcViewer matching-folders control currently renders folder suggestions as a conventional
indented multi-row tree using BrightIdeasSoftware.TreeListView (QuickFiler/Viewers/EfcViewer.cs,
QuickFiler/Viewers/EfcViewer3.cs, plus their Designer files). The intended design is a single-line
breadcrumb per suggestion anchored at the selected leaf. The current hierarchy is synthesized by
FolderSuggestionTree.BuildFromRows via prefix-matching over the top-ranked suggestion rows, so
expanding a folder does not reveal its real Outlook subfolders. The prediction percentage is also
reported as obscured at runtime even though static column/rect math shows no overlap.
TreeListView (as currently used) does not naturally support single-line breadcrumb rendering with
per-segment double-click collapse, and it is a VSTO/WinForms-hosting-specific investment that would
not carry forward to the planned VSTO migration. The redesign targets WebView2 (HTML/CSS/JS), which
is largely reusable across a post-VSTO UI stack and reuses a dependency already proven in this
codebase (QuickFiler's WebView2 message-body pane, including the cid: fix from feature 326).
Proposed Behavior
Replace the EfcViewer matching-folders TreeListView in both EfcViewer and EfcViewer3 with a
WebView2-hosted HTML/CSS/JS breadcrumb control that:
- Renders each suggestion as a single-line breadcrumb
Folder -> SubFolder -> Leaf anchored at the
selected/predicted leaf.
- Shows an expand affordance (plus when collapsed, minus when expanded) only on the leaf, and only
when the leaf has subfolders.
- Collapses a row on double-click of a non-leaf segment, hiding everything after that segment and
showing a plus to re-expand back to the full breadcrumb.
- On expand of a segment, lists every real immediate Outlook subfolder of that folder via the
shared live folder-hierarchy provider from feature 9101 (not prefix-matching over suggestion rows).
- Keeps the prediction percentage always fully visible: first capture a runtime reproduction of the
current obscuring defect, then apply a CSS-based fix.
A JS<->.NET event bridge carries double-click and keyboard (left/right arrow) interaction and routes
the live subfolder query across the WebView2 boundary. The percentage plumbing (feature 324) is reused
as-is; the scoring/ranking algorithm is not changed.
Acceptance Criteria
Constraints & Risks
- Depends on issue 9101 (live Outlook folder-hierarchy provider), which is merged before this feature
during epic execution. This feature consumes 9101's contract (ancestor chain + on-demand real
immediate subfolders behind an injectable seam) rather than re-deriving hierarchy from suggestion rows.
- Ruled out:
BrightIdeasSoftware.TreeListView (or any third-party WinForms tree/list control) and
WPF/ElementHost.
- The live Outlook subfolder query is I/O-bound and must be isolated from pure breadcrumb logic per
the repository I/O-boundary policy so the core is unit-testable without a live Outlook process.
- Two parallel non-shared EfcViewer implementations (
EfcViewer, EfcViewer3) must both be converted.
- WinForms/WebView2 host wiring and Designer-generated code are coverage-exempt per policy; testable
pure logic (breadcrumb model, bridge message shaping) is not exempt and must meet coverage floors.
Test Conditions
Source
From: docs/features/potential/2026-07-16-efcviewer-breadcrumb-webview2.md
Problem / Why
The EfcViewer matching-folders control currently renders folder suggestions as a conventional
indented multi-row tree using
BrightIdeasSoftware.TreeListView(QuickFiler/Viewers/EfcViewer.cs,QuickFiler/Viewers/EfcViewer3.cs, plus their Designer files). The intended design is a single-linebreadcrumb per suggestion anchored at the selected leaf. The current hierarchy is synthesized by
FolderSuggestionTree.BuildFromRowsvia prefix-matching over the top-ranked suggestion rows, soexpanding a folder does not reveal its real Outlook subfolders. The prediction percentage is also
reported as obscured at runtime even though static column/rect math shows no overlap.
TreeListView(as currently used) does not naturally support single-line breadcrumb rendering withper-segment double-click collapse, and it is a VSTO/WinForms-hosting-specific investment that would
not carry forward to the planned VSTO migration. The redesign targets WebView2 (HTML/CSS/JS), which
is largely reusable across a post-VSTO UI stack and reuses a dependency already proven in this
codebase (QuickFiler's WebView2 message-body pane, including the
cid:fix from feature 326).Proposed Behavior
Replace the EfcViewer matching-folders
TreeListViewin bothEfcViewerandEfcViewer3with aWebView2-hosted HTML/CSS/JS breadcrumb control that:
Folder -> SubFolder -> Leafanchored at theselected/predicted leaf.
when the leaf has subfolders.
showing a plus to re-expand back to the full breadcrumb.
shared live folder-hierarchy provider from feature 9101 (not prefix-matching over suggestion rows).
current obscuring defect, then apply a CSS-based fix.
A JS<->.NET event bridge carries double-click and keyboard (left/right arrow) interaction and routes
the live subfolder query across the WebView2 boundary. The percentage plumbing (feature 324) is reused
as-is; the scoring/ranking algorithm is not changed.
Acceptance Criteria
EfcViewerandEfcViewer3).Constraints & Risks
during epic execution. This feature consumes 9101's contract (ancestor chain + on-demand real
immediate subfolders behind an injectable seam) rather than re-deriving hierarchy from suggestion rows.
BrightIdeasSoftware.TreeListView(or any third-party WinForms tree/list control) andWPF/
ElementHost.the repository I/O-boundary policy so the core is unit-testable without a live Outlook process.
EfcViewer,EfcViewer3) must both be converted.pure logic (breadcrumb model, bridge message shaping) is not exempt and must meet coverage floors.
Test Conditions
Source
From: docs/features/potential/2026-07-16-efcviewer-breadcrumb-webview2.md