ObjectDisposedException on WCF ServiceChannel after navigation — regression introduced by PR #5229 (OnBrowserDestroyed no longer cleaning up JavascriptBindingSettings)

[rchakraborty1983]

CefSharp version: 146.0.100
Previous working version: 144.0.120
Platform: WPF, .NET Framework, Windows

Background:
We use a WCF Named Pipe channel created in OnBrowserCreated (inside WcfEnabledSubProcess) to back our synchronous JavaScript-to-C# bridge (servicesBridgeSync). This channel is closed in OnBrowserDestroyed.
In CefSharp 144, after a save operation that causes internal navigation, OnBrowserCreated would re-fire and re-open the WCF channel. In CefSharp 146, after PR #5229 changed CefAppUnmanagedWrapper.cpp so that OnBrowserDestroyed intentionally does not clean up JavascriptBindingSettings, we observe that OnBrowserCreated no longer re-fires reliably after navigation in our scenario.
The result is that JavascriptMethodWrapper._browserProcess holds a reference to the disposed ServiceChannel. Any subsequent synchronous bridge call (e.g. a parent dataset dropdown triggering GetDataSetValues) throws:
ObjectDisposedException: Cannot access a disposed object.
Object name: 'System.ServiceModel.Channels.ServiceChannel'.

Question:
Is the behaviour change in OnBrowserDestroyed (PR #5229 / Issue #5228) intentional for all consumers, or is there a supported way to ensure OnBrowserCreated still fires after navigation when using a custom subprocess with WCF-backed sync bindings?
Current workaround: We wrapped the sync bridge call in a try/catch and fall back to the async IPC path (servicesBridge.GetDataSetValues) on failure. This resolves the ObjectDisposedException symptom, but we'd prefer the WCF channel to be properly re-established rather than silently bypassing the sync path.
Is a fix or an opt-in mechanism planned that would allow the subprocess to hook OnBrowserCreated reliably again, or is the recommended path now to move fully to the async bridge?

[amaitland]

after PR #5229 changed CefAppUnmanagedWrapper.cpp so that OnBrowserDestroyed intentionally does not clean up JavascriptBindingSettings,

The binding settings shouldn't be related to the WCF channel. This PR was to workaround the CEF/Chromium issue.

we observe that OnBrowserCreated no longer re-fires reliably after navigation in our scenario.

That's a bug that needs to be fixed in CEF (possibly Chromium).

This resolves the ObjectDisposedException symptom, but we'd prefer the WCF channel to be properly re-established rather than silently bypassing the sync path.

I'd suggest waiting until M147 is out (still waiting for CEF to release a stable version).

If the problem reproduces then, create an issue at https://github.com/chromiumembedded/cef/issues/

If you create an issue now, you'll just get asked to confirm the problem reproduces in M147

Is a fix or an opt-in mechanism planned that would allow the subprocess to hook OnBrowserCreated reliably again

Again, needs to be fixed in CEF/Chromium. #5229 was required as OnBrowserCreated/OnBrowserDestroyed are no longer reliably called in some circumstances.

It maybe a Chromium behavior changed.

https://www.magpcss.org/ceforum/viewtopic.php?f=6&t=20428&hilit=OnBrowserDestroyed#p58064

or is the recommended path now to move fully to the async bridge?

That has been the recommendation for quite a few years.

[amaitland]

I'd suggest waiting until M147 is out (still waiting for CEF to release a stable version).

M147 is now out, if the problem still reproduces then you'll need to create an issue on https://github.com/chromiumembedded/cef/issues/