BindObjectAsync reports successful binding, but sync-bound object is undefined on window after navigation

[SwapnojHyland]

Environment

• CefSharp: 146.0.70 / 146.0.100
• Regression from: 144.0.120 (Chromium 120) → 146.0.70 (Chromium 122)

---

Application Context

We are embedding CefSharp in a WPF desktop application that hosts a
data viewer component— it renders server-side
HTML pages inside a ChromiumWebBrowser control.

The typical user flow that triggers the issue:

1. User opens an object in the viewer — browser loads the viewer HTML page.
   C# registers a service object (isAsync=false) and invokes
   CefSharp.BindObjectAsync() via EvaluateScriptAsync — works correctly on
   first load.

2. User performs an action (refresh, save, navigate to a different object).
   The viewer clears the browser to about:blank while the server request is
   in flight (visual reset), then navigates to the new object's URL once the
   server responds.

3. C# re-registers the service object and invokes CefSharp.BindObjectAsync()
   again via EvaluateScriptAsync for the new page — this is where the failure
   occurs.

On the C# side, the object is registered via
JavascriptObjectRepository.Register(name, obj, isAsync: ...) and then
CefSharp.BindObjectAsync('name') is triggered using IFrame.EvaluateScriptAsync
— the Promise object is returned as the result but not awaited on the C# side.
We also tried properly awaiting the Promise by switching to
IFrame.EvaluateScriptAsPromiseAsync with the body
"await CefSharp.BindObjectAsync('name'); return true;" — this did not resolve
the issue. The binding still reported success but the object remained absent from
window. The loaded HTML page then references the bound object by name; on
failure window[syncObjectName] is undefined and a ReferenceError is thrown.

The about:blank intermediate navigation is intentional (visual clear during
the async round-trip) but we confirmed that removing it does not fix the issue —
CefSharp itself generates about:blank V8 contexts during navigation, so the
race persists regardless.

---

Problem

After upgrading from CefSharp v144.0.120 to v146.0.70 / v146.0.100, a C#
object registered via JavascriptObjectRepository.Register() and bound using
CefSharp.BindObjectAsync() reliably fails to appear on window when the
DevTools panel is open — specifically from the 2nd or subsequent page
navigation onward. The Binding API reports {Success:true, Count:1} every
time, but when a subsequent EvaluateScriptAsync call tries to use the object,
it throws:

Uncaught ReferenceError: <boundObjectName> is not defined
    at about:blank:1:64

(about:blank:1:64 is CefSharp's internal source location label for
EvaluateScriptAsync calls — it does not indicate an actual about:blank page.)

The same object registered with isAsync=true works correctly — always present
on window, DevTools open or not.

---

Minimal reproduction steps

1. Register an object with isAsync=false
2. Open DevTools
3. Refresh the page twice
4. On the 2nd refresh, call the bound object from JS → undefined

---

What we observed

• BindObjectAsync returns Success=true in ~2ms → cache-hit path, not
  an IPC round-trip (~30ms would indicate full IPC path)
• window[objName] is undefined immediately after and stays undefined
  indefinitely (polled for 10 seconds, 50 retries × 200ms)
• Switching to isAsync=true resolves the issue completely and immediately

---

Root cause hypothesis (from source reading)

We believe three things combine to cause this:

1. The failure is consistently reproducible when DevTools is open.

Opening DevTools is the reliable trigger — the issue does not occur without it.
We suspect something in the DevTools inspector isolated world lifecycle interacts
with OnContextReleased / TryRemove in a way that evicts the newly-created
rootObjectWrapper, but we haven't been able to confirm the exact ordering change
without access to a debug CEF build. We'd welcome any insight into what DevTools
changes about the V8 context lifecycle in Chromium 122 vs 120.

2. _browserProcess = null → Bind() silently skips the sync object.

JavascriptRootObjectWrapper::Bind() in the isAsync=false (#ifndef NETCOREAPP)
branch:

if (_browserProcess == nullptr)
{
    LOG(ERROR) << "IBrowserProcess is null, unable to bind...";
    continue;  // no exception, no signal to C#
}

The evicted wrapper's _browserProcess is null (its OnBrowserDestroyed already
ran). The object is never placed on window. C# calling code receives no error.

3. Cache-hit path in BindObjectAsyncHandler::Execute reports false-positive
success.

From BindObjectAsyncHandler.h (cache-hit branch, ~line 150):

rootObject->Bind(cachedObjects, context->GetGlobal());  // silently skips sync obj

// Resolves unconditionally regardless of whether Bind() placed anything on window:
auto promiseResolveScript = StringUtils::ToNative(
    "Promise.resolve({Success:true, Count:" + cachedObjects->Count + ", Message:'OK'});");

cachedObjects->Count > 0 is always true after the first page load (object
descriptor is cached), so the promise always resolves Success:true without
verifying window presence. This is a false positive that hides the failure
entirely from C# code.

Why only 2nd+ refresh with DevTools:

First refresh: DevTools hasn't fully initialized its
addScriptToEvaluateOnNewDocument hook yet — inspector OnContextReleased
still fires before the new main world's OnContextCreated. Safe order. Passes.

2nd+ refresh: Inspector isolated world lifecycle is now fully synchronized with
page navigation. Fires after new main world OnContextCreated. Reliably
triggers the eviction race.

---

Questions for maintainers

1. Is our understanding of the Chromium M122 OnContextReleased ordering change
   correct? Was this a deliberate CEF change or an unintended side-effect?

2. Is there a planned CefSharp-level workaround until CEF Chromium Site Isolation - Legacy Binding Test failure #3867 is resolved —
   e.g. skipping TryRemove in OnContextReleased when the frame's
   rootObjectWrapper is currently referenced by a live BindObjectAsyncHandler?

3. Would it be reasonable for the cache-hit path in BindObjectAsyncHandler::Execute
   to verify actual window presence after Bind() — i.e. check
   global->HasValue(objectName) for each cached object before resolving
   Success:true? That would at least surface the failure to C# rather than
   returning a false positive.

4. For applications that cannot migrate to isAsync=true (WCF sync call semantics
   required), is passing {ignoreCache:true} to CefSharp.BindObjectAsync() a
   viable workaround to force the full IPC path on every bind call, thereby
   bypassing the evicted-wrapper issue?

5. Can you confirm why isAsync=true is immune to this issue across all three
   versions (144.0.120, 146.0.70, 146.0.100)? Our reading of the source suggests
   JavascriptAsyncObjectWrapper::Bind() calls v8Value->SetValue() unconditionally
   with no _browserProcess dependency, so it places the proxy on window
   regardless of rootObjectWrapper lifecycle state. If that is correct and
   architecturally guaranteed to remain stable, it would give us confidence to
   ship isAsync=true as a permanent fix rather than treating it as a temporary
   workaround pending an upstream CEF fix.

---

Workaround found

Changing registration to isAsync=true fully resolves the issue. JavaScript
callers already used async/await so no behavior change was needed on the JS side.
Noting this in case it helps other users hitting the same symptom.

---

References

• PR Fixed duplicate calls to OnContextCreated #5073 — isSameContext guard added to OnContextCreated; OnContextReleased
  guard explicitly not possible (AV crash confirmed in PR discussion)
• Issue v146.0.70 JavaScript CefSharp object not availlable when loading via GET -> POST -> POST (iframe) #5228 — Documents browserWrapper null → window.CefSharp not injected race
• PR Allow JavaScript binding when browser wrapper cannot be found #5229 — Fixes window.CefSharp injection gap (different symptom; does not fix
  the isAsync=false DevTools eviction bug described above)
• PR Move LegacyBindingEnabled / JavascriptBindingPropertyName to per browser settings #5231 — Follow-up cleanup (open)
• CEF issue Chromium Site Isolation - Legacy Binding Test failure #3867 — Root upstream request: pass world_id to OnContextReleased