Bug: webview2breadcrumbhost-handler-retention-pooled-viewer

[drmoisan]

• Work Mode: full-bug

Summary

WebView2BreadcrumbHost's constructor performs an unhook-then-hook sequence intended to be
idempotent across pooled-viewer reuse, but the unhook cannot remove the previous instance's
subscription. When a new WebView2BreadcrumbHost is constructed over a WebView2 control that a
prior host instance already wrapped, the prior instance stays subscribed to the control's
CoreWebView2InitializationCompleted event. The old host is kept alive by the control, and
initialization completion is handled more than once.

Environment

• OS/version: Windows 11 Pro 10.0.26200
• Runtime: .NET Framework 4.8.1 WinForms VSTO add-in with Microsoft WebView2
• Affected path: pooled viewer reuse (EfcViewerQueue / ItemViewerQueue recycling a viewer whose
  Designer-owned WebView2 control is retained across uses)

Steps to Reproduce

1. Construct a WebView2BreadcrumbHost over a Designer-owned WebView2 control.
2. Recycle the pooled viewer so a second WebView2BreadcrumbHost is constructed over the same
   control instance.
3. Drive CoreWebView2 initialization to completion.
4. Observe that both host instances handle the completion: IsCoreInitialized is set and
   CoreInitialized is raised on the stale instance as well as the live one.

Expected Behavior

Exactly one host instance - the current one - is subscribed to the control's events, and exactly
one CoreInitialized notification reaches the controller per initialization.

Actual Behavior

Both instances remain subscribed. The stale instance is retained for the lifetime of the control.

Logs / Screenshots

(not provided in potential file)

Impact / Severity

• Blocker
• High
• Medium
• Low

Consequences are a managed-object retention leak (each recycled viewer accumulates one dead host
plus its event-handler chain) and duplicated CoreInitialized / MessageReceived notifications
routed to BreadcrumbBridgeRouter.NotifyCoreInitialized. Duplicate notification can produce
duplicate breadcrumb document initialization work. Severity is Medium rather than High because the
stale host's handler does not throw and the observable breadcrumb output is idempotent in the
common path.

Source

From: docs/features/potential/2026-08-07-webview2breadcrumbhost-handler-retention-pooled-viewer.md

[drmoisan]

Second pooled-viewer defect in the same file: InitializeAsync is not idempotent

Found during the same #455 preparation research. Filing here rather than separately because it is the same file, the same pooled-viewer reuse path, and almost certainly the same fix.

QuickFiler/Viewers/WebView2BreadcrumbHost.cs:86-89 documents:

Initializes the CoreWebView2 through the IWebViewCoreInitializer seam... Safe to re-run for pooled viewers.

InitializeAsync (:92-113) has no idempotence guard. Every call unconditionally:

1. recomputes the cache folder (:99-102),
2. allocates a new CoreWebView2EnvironmentOptions (:103),
3. awaits _initializer.CreateEnvironmentAsync(...) — creating a fresh environment (:108-111),
4. calls _initializer.EnsureCoreWebView2Async(_control, environment) (:112).

There is no check of IsCoreInitialized, no in-flight guard, and no CancellationToken. A second call while the first is still awaiting produces two concurrent initialization attempts against one control.

So the "safe to re-run" claim in the doc comment is not implemented. Combined with the handler-retention defect in the issue body, the pooled-viewer re-initialization path is unsound in two independent ways:

• the stale host stays subscribed (issue body), and
• each re-initialization builds a new environment rather than reusing the initialized core (this comment).

Suggested remediation

Handle both together: give the host an explicit lifecycle (attach / detach / dispose) rather than relying on constructor-side unhooking and an unguarded re-entrant InitializeAsync. A single in-flight Task field plus an IsCoreInitialized short-circuit covers the idempotence half.

Related

• Bug: webview2breadcrumbhost-unmarshalled-sdk-call-and-unsynchronized-state #476 — unmarshalled SDK calls and unsynchronized IsCoreInitialized in the same file. All three are lifecycle/threading defects in WebView2BreadcrumbHost and should be scheduled as one change.
• Bug: iwebviewcoreinitializer-contract-defects #477 — IWebViewCoreInitializer contract defects, including that CreateEnvironmentAsync hard-codes browserExecutableFolder to null.
• Feature: quickfiler-breadcrumb-dropdown-webview-coverage #455 / Feature: quickfiler-80-per-file-coverage #136 — the coverage child that found these; it carries a no-behavior-change NFR and cannot fix them.