Bug: breadcrumb-webview2-init-fails-resource-not-in-correct-state #792

Activity

1. drmoisan

   added

   bugSomething isn't workingSomething isn't working

   on Sep 6, 2026
2. drmoisan commented on Sep 7, 2026

   

   drmoisan

   on Sep 7, 2026

   OwnerAuthor

   More actions

   Update 2026-09-06: reproduces on every Efc open via pop-out and Sort Email; severity raised to High

   Two user-visible symptoms reported today are this failure:

   1. Pop-out from a QfcItem to an EfcItem shows an empty folder list. No suggestions, no banners, and typing a search string does nothing.
   2. Ribbon -> Sort Email opens an EfcViewer whose "Matched Folders:" section has no entries. The label is a static WinForms label above the breadcrumb WebView2, which is why it survives while the list is blank.

   Log evidence

   TaskMaster\bin\Debug\logs\debug_2026-09-06.log records the paired WebView2BreadcrumbHost / EfcFormController initialization failure with HRESULT 0x8007139F on every Efc open in the session: ten pop-out opens between 17:39:00 and 17:41:42, three at 19:04-19:06, and the Sort Email open at 19:56:36 (the SortEmail_Click stack at 19:56:36,171 is followed by the failure at 19:56:37,940). Today the failure is deterministic on the Efc entry points, not intermittent as originally recorded.

   2026-09-06 19:56:37,940 [VSTA_Main] ERROR QuickFiler.Viewers.WebView2BreadcrumbHost - Breadcrumb CoreWebView2 initialization failed: The group or resource is not in the correct state to perform the requested operation. (Exception from HRESULT: 0x8007139F)
   2026-09-06 19:56:38,004 [VSTA_Main] ERROR QuickFiler.Controllers.EfcFormController - Breadcrumb WebView2 initialization failed: The group or resource is not in the correct state to perform the requested operation. (Exception from HRESULT: 0x8007139F)
   

   Why the list is blank rather than degraded

   • BreadcrumbBridgeRouter.DeliverDocument (QuickFiler\Controllers\BreadcrumbBridgeRouter.Selection.cs:168-180) stashes the rendered document in _pendingDocument when _host.IsCoreInitialized is false. WebView2BreadcrumbHost (:330-342) returns on !e.IsSuccess without ever raising CoreInitialized, so the pending document is never navigated. There is no fallback rendering and no retry.
   • EfcFormController.InitializeBreadcrumbHostAsync (:1071-1081) and PopulateFolderCombobox (:1250-1271) are fire-and-forget tasks with total catch blocks, so the failure is log-only.
   • EfcFormController.BindBreadcrumbRowsAsync (:1115-1118) reads _globals.Ol.ArchiveRootPath unguarded; TryGetArchiveRoot (EfcDataModel.cs:280-297) is not used on the bind path.

   Additional latent defect on the pop-out path

   QfcCollectionController.PopOutControlGroup (QuickFiler\Controllers\QfcCollectionController.cs:710-735) hands only the raw MailItem and _globals to new EfcHomeController(...) via the synchronous constructor, so the Efc view rebuilds prediction from scratch with an unloaded MailItemHelper (EfcDataModel.cs:48-81 vs CreateAsync :89-142). The in-QuickFiler carry pattern from #678 (QfcItemController.FolderHandling.cs:68-83, _carriedFolderHandler) is not applied to the pop-out. EfcViewerQueue.BuildQueue has no production call site, so EfcViewer is always constructed inline on the calling thread and captures SynchronizationContext.Current as-is (EfcViewer.cs:23-30); if the pop-out continuation lands off the UI thread, UiThread.SynchronizationContextAwaiter throws on the null context (UiThread.cs:91-98) inside the same swallowed tasks.

   Additional acceptance criteria (settled with the maintainer 2026-09-06)

   • AC-U1: A failed CoreWebView2 initialization is retried, and on final failure the Efc view shows a visible error state in the folder area instead of a blank list.
   • AC-U2: _pendingDocument is never silently dropped: it is delivered when initialization later succeeds or an error is surfaced.
   • AC-U3: The pop-out path carries the already-initialized folder predictor and loaded MailItemHelper from the QfcItem, following the Bug: quickfiler-carry-folder-predictor-to-item-controller #678 carry pattern, and constructs the EfcViewer on the UI thread.
   • AC-U4: PopulateFolderCombobox and InitializeBreadcrumbHostAsync report failures through TryReportBoundaryFault to the user, not log-only.
   • AC-U5: Manual verification on both entry points: pop-out from QuickFiler and ribbon Sort Email each show suggestion rows and respond to typed search.

   Severity: raised from Medium to High. Both Efc entry points are unusable for folder selection in the affected sessions.
3. drmoisan commented on Sep 17, 2026

   

   drmoisan

   on Sep 17, 2026

   OwnerAuthor

   More actions

   Diagnosis refreshed against current main (2026-09-17) — defect still present

   The branch bug/breadcrumb-webview2-init-fails-resource-not-in-correct-state-792 has been merged up to current main (HEAD 8d3ea6426, zero conflicts). All three mechanisms from the original diagnosis are intact. Nothing merged in the intervening fourteen items touched any part of the mechanism.

   1. The three WebView2 environment sites still diverge — STILL PRESENT

   The user-data folder agrees across all three (%LocalAppData%\WindowsFormsWebView2, the same Path.Combine expression duplicated three times). The additional browser arguments do not.

   Site	File:line	Additional browser arguments
   EFC form breadcrumb	QuickFiler/Viewers/WebView2BreadcrumbHost.cs:250	none — default-constructed options
   QFC item viewer	QuickFiler/Controllers/QfcItemController.ViewerSetup.cs:62	"--incognito " — inline literal
   Efc pop-out item viewer	QuickFiler/Controllers/EfcItemController.cs:188-190	"--incognito " via IncognitoArgument at :177

   Same user-data folder plus differing AdditionalBrowserArguments against a shared browser process is exactly the documented 0x8007139F condition.

   New obstacle for AC-U6, not present when the spec was written. EfcItemController.IncognitoArgument now exists at :177, and its XML doc at :168-176 — plus a sibling comment at EfcItemController.WebViewFaultBoundary.cs:10-12 — states it is deliberately not shared: "Named distinctly so no shared contract ... is implied." So AC-U6 must now reverse an explicit anti-contract and its documentation, not merely hoist a literal. No cross-site equality test exists; the only binding test is QuickFiler.Test/Controllers/EfcItemControllerTests.cs:372-378, which asserts the single EFC constant.

   Site 3 also still bypasses the IWebViewCoreInitializer seam, calling CoreWebView2Environment.CreateAsync directly at :195-199.

   2. The pending document is still silently discarded — STILL PRESENT, verbatim

   _pendingDocument lives in the router, not the host. Stashed at BreadcrumbBridgeRouter.Selection.cs:168-180 when IsCoreInitialized is false. The only drain is BreadcrumbBridgeRouter.cs:320-329 (NotifyCoreInitialized), reachable from exactly one production wire-up at EfcFormController.cs:1064, which subscribes to CoreInitialized.

   That event is raised only on the success path. On failure, WebView2BreadcrumbHost.cs:330-353:

   if (!e.IsSuccess)
   {
       log.Error($"Breadcrumb CoreWebView2 initialization failed: ...", e.InitializationException);
       return;                                  // :341 — no event, no retry, no error document
   }

   So the document is discarded, the outbound queue at :328 is never drained, and there is no retry anywhere: InitializeAsync (:239-270) is a single straight-line attempt with no loop and no re-entry trigger.

   3. Failure surfacing — SPLIT, and the defect half remains

   • PopulateFolderCombobox is correct. EfcFormController.cs:1268-1271 calls TryReportBoundaryFault at line 1270 — exactly where the original spec said it was. That half of AC-U4 is genuinely already satisfied.
   • InitializeBreadcrumbHostAsync is log-only. EfcFormController.cs:1072-1082, catch at :1080 calls logger.Error and nothing else, despite TryReportBoundaryFault being defined at :150-168 in the same class and used by six other catch blocks (:556, :573, :591, :653, :668, :1015, :1127). Its caller at :1067 is fire-and-forget, so nothing downstream observes it.

   Partial progress since the diagnosis: the EFC item path is now guarded (EfcItemController.cs:158 plus EfcItemController.WebViewFaultBoundary.cs:25-42, from issue #726), so these tasks are caught rather than silently finalized. But that guard's sink defaults to logger.Error with no user-visible path, and its doc explicitly disclaims any contract with EfcFormController.BoundaryErrorSink. Nothing reaches the user on any WebView2 initialization path.

   Stale figures in the current spec, correct before re-planning

   File	Current	Spec said
   EfcFormController.cs	1181	1181 — still accurate
   EfcHomeController.cs	386	447 — stale
   EfcItemController.cs	998	—
   QfcCollectionController.cs	2032	—
   WebView2BreadcrumbHost.cs	328	—

   EfcHomeController has since been partialed across six files, so the spec's "447 lines, roughly 53 of headroom" risk is obsolete — there is more room and a different structure. EfcFormController.cs (1181) and EfcItemController.cs (998) both exceed the 500-line ceiling before any change, which AC-U8 must account for.

   What static analysis could not establish

   Recorded explicitly so it is not mistaken for evidence of a fix:

   1. Whether 0x8007139F actually fires at runtime. The argument divergence is the documented cause pattern and is demonstrably in the source; whether the Evergreen runtime rejects this pairing in this process, and which site loses, needs a live session.
   2. Which site wins the shared browser process depends on runtime ordering between the three, which is not statically resolvable.
   3. Whether the empty folder list has any additional cause beyond the pending-document drop.
   4. Whether the Designer-set CoreWebView2CreationProperties (ItemViewer.Designer.cs:195,241 and three siblings, all null) are truly inert given an explicit environment is passed to EnsureCoreWebView2Async. SDK precedence for that combination was not verified.

   Sections 1 and 2 are demonstrably present in the code — the quoted lines are the defect, unmodified. Items 1-4 above are could not confirm from reading, which is a different finding and does not support closing.

   Disposition: remains open. Diagnosis confirmed, plan to be regenerated against current main.
4. drmoisan commented on Sep 18, 2026

   

   drmoisan

   on Sep 18, 2026

   OwnerAuthor

   More actions

   Delivered by PR #910, merged as 734112ed25bba293cb074e71fee2286bc3b72fae

   93 of 93 plan tasks, 9 of 9 acceptance criteria. Single clean toolchain pass: format rewrote nothing in the write set; analyzer and nullable rebuilds both 0 errors / 0 warnings with 36 csc invocations and zero skipped CoreCompile; 1468/1468 tests; 452/452 on the TaskMaster.Test sweep. Coverage moved up: QuickFiler package 81.73 → 82.01% line, 78.04 → 78.24% branch, rolled up from class elements rather than trusting the Cobertura attribute.

   Root cause — a regression from #463, not present in the original diagnosis

   The additional-browser-arguments literal opened with a U+2013 en dash rather than two ASCII hyphens, so it was never a recognised Chromium switch and no site effectively passed one. When #463 corrected the dash to ASCII on 2026-08-27 the argument became real, and two of the three WebView2 environment sites began passing it while the breadcrumb host continued passing none. Same user-data folder, differing AdditionalBrowserArguments, shared browser process — the documented 0x8007139F condition.

   The fix

   Converges all three sites on one shared owner (WebView2EnvironmentContract); routes the Efc item site through the mockable initializer seam it had been bypassing; retries a failed CoreWebView2 initialization; surfaces final failure as a visible error state instead of dropping it; and drains the pending document and outbound queue on the failure path rather than only on the success path.

   Convergence direction settled on evidence, not on the regression history

   An audit of the three files that generate the breadcrumb document found zero use of any browser storage API — no localStorage, sessionStorage, indexedDB, document.cookie, navigator.storage, caches. or openDatabase — and no external resource reference. The spec records explicitly that the #463 history is a separate and independent reason against the alternative direction, and is not what closes the storage question.

   AC-U5 — discharged by live manual verification, 2026-09-17

   Against a session running the rebuilt add-in, confirmed by registry manifest resolution to the item-worktree build. All four required observations held:

   1. Suggestion rows on the QuickFiler pop-out entry point, not a blank list — maintainer-confirmed
   2. Rows responding to typed search — maintainer-confirmed
   3. Suggestion rows under "Matched Folders:" on the ribbon Sort Email entry point — maintainer-confirmed
   4. Zero occurrences of Breadcrumb CoreWebView2 initialization failed or 0x8007139F in the session log — instrument-verified with positive controls

   The log check was the discriminating observation. Because the fix adds retry, a session could have looked entirely correct to an observer while initialization was still failing and silently recovering. A clean log distinguishes a genuine convergence from a retry masking a conflict that still occurs.

   One finding for separate triage

   A structural-parity gate searching for the literal text new CoreWebView2EnvironmentOptions matches a commented-out dead line at QfcItemController.ViewerSetup.cs:61 while missing the live target-typed construction at :62, and would therefore pass on an unfixed tree. Any such gate must enumerate by type name, exclude comment text, and be observed failing before it is trusted.

   Closing manually — closingIssuesReferences was empty by design.
5. drmoisan commented on Sep 18, 2026

   

   drmoisan

   on Sep 18, 2026

   OwnerAuthor

   More actions

   Delivered by PR #910, merged as 734112e. See the preceding comment for the full delivery record, including the #463 regression root cause and the AC-U5 live verification.
6. drmoisan

   closed this as completedon Sep 18, 2026