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
SelectRow sets both _selectedRowId and SelectedFolderPath.
- 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
Impact / Severity
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
Summary
BreadcrumbBridgeRouter.BindRowsAsyncclears_selectedRowIdbut does not clearSelectedFolderPath. After a re-bind the UI shows no row highlighted whileEfcFormController.SelectedFolderstill reports the previously selected folder. BecauseBindFolderRowsruns on every search keystroke, a confirm action taken at that moment can file mailto a folder the user can no longer see selected.
Environment
Steps to Reproduce
SelectRowsets both_selectedRowIdandSelectedFolderPath.EfcFormController.BindFolderRows(QuickFiler/Controllers/EfcFormController.cs:873-883) and soBreadcrumbBridgeRouter.BindRowsAsync.Expected Behavior
After a re-bind clears the visible selection, the controller's
SelectedFoldershould agree with theUI: either no folder is reported as the filing target, or the selection is visibly restored. The two
state fields
_selectedRowIdandSelectedFolderPathare written together inSelectRowand shouldbe cleared together.
Actual Behavior
Only
_selectedRowIdis cleared.SelectedFolderPathretains the previous value, soEfcFormController.SelectedFolderkeeps returning the old folder while the UI shows nothingselected. A move performed at that point targets the stale folder.
Logs / Screenshots
Impact / Severity
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
BindFolderRowsruns on every keystroke, so the divergent window is common rather thanrare, and the failure is silent.
Source
From: docs/features/potential/2026-08-08-breadcrumb-router-stale-selectedfolderpath-after-rebind.md