Repository navigation
Bug: breadcrumb-router-stale-selectedfolderpath-after-rebind #499
Description
- Work Mode: full-bug
Summary
BreadcrumbBridgeRouter.BindRowsAsync clears _selectedRowId but does not clear
SelectedFolderPath. After a re-bind the UI shows no row highlighted while
EfcFormController.SelectedFolder still reports the previously selected folder. Because
BindFolderRows runs on every search keystroke, a confirm action taken at that moment can file mail
to a folder the user can no longer see selected.
Environment
- OS/version: Windows 11 Pro 10.0.26200
- Python version: n/a (C# / .NET Framework 4.8.1 WinForms VSTO add-in with Microsoft WebView2)
- Command/flags used: n/a - reached through the EfcViewer folder-list breadcrumb surface
- Data source or fixture: any folder set where a selection is made and then the search text changes
Steps to Reproduce
- Open the EfcViewer folder list and type enough search text to show candidate folder rows.
- Select a folder row, so
SelectRowsets both_selectedRowIdandSelectedFolderPath. - Type one more character in the search box. This reaches
EfcFormController.BindFolderRows(QuickFiler/Controllers/EfcFormController.cs:873-883) and so
BreadcrumbBridgeRouter.BindRowsAsync. - Observe that no row is highlighted in the re-rendered document.
- Trigger a move or folder-open action.
Expected Behavior
After a re-bind clears the visible selection, the controller's SelectedFolder should agree with the
UI: either no folder is reported as the filing target, or the selection is visibly restored. The two
state fields _selectedRowId and SelectedFolderPath are written together in SelectRow and should
be cleared together.
Actual Behavior
Only _selectedRowId is cleared. SelectedFolderPath retains the previous value, so
EfcFormController.SelectedFolder keeps returning the old folder while the UI shows nothing
selected. A move performed at that point targets the stale folder.
Logs / Screenshots
- Attached minimal logs or screenshot
- Snippet: n/a - this is a silent state divergence with no error text.
Impact / Severity
- Blocker
- High
- Medium
- Low
Rationale: the consequence is mail filed to an unintended folder - a silent, user-visible data
placement error with no exception to signal it. Recorded by research as Medium-High; raised to High
here because BindFolderRows runs on every keystroke, so the divergent window is common rather than
rare, and the failure is silent.
Source
From: docs/features/potential/2026-08-08-breadcrumb-router-stale-selectedfolderpath-after-rebind.md
Activity
docs(495): F12 lifecycle-coordinator research, feature docs, defect p…
docs(498): salvage prepared breadcrumb router feature documents
drmoisan commentedon Sep 1, 2026
Closing as completed. Delivered under the sibling feature
breadcrumb-router-navigation-defects-498, commit0c9dcf42("fix(quickfiler): clear stale SelectedFolderPath on re-bind (#499)"), an ancestor oforigin/main. The commit subject names this issue directly — this repository does not use GitHub closing keywords in any commit message, so the issue never auto-closed despite the direct reference.Confirmed directly against
origin/main:QuickFiler/Controllers/BreadcrumbBridgeRouter.cs(BindRowsAsync, lines 138-146):_selectedRowIdandSelectedFolderPathare now cleared together on re-bind, withSelectedFolderPathChangedraised only when the previous value was non-null — exactly the fix this issue asked for.The delivering spec (
docs/features/active/breadcrumb-router-navigation-defects-498/spec.md) declares "Also closes: #440, #499" and carries all 31 acceptance criteria checked, including the four (AC-4, AC-5, AC-6, AC-26) that name this issue.Verified during an admission check against the
bugs-638-644-647parallel run (2026-09-01). No branch or PR remains to ship; this was left open only as bookkeeping.