Error while fulfilling of JS: Request BrowserId : 1 not found it's likely the browser is already closed

Is there an existing issue for this?

I have searched both open/closed issues, no issue already exists.

CefSharp Version

117.2.40

Operating System

Windows 10

Architecture

x64

.Net Version

.net 6.0

Implementation

OffScreen

Reproduction Steps

Version: Above 108

Steps:
Create instance of CefSharp.OffScreen.ChromiumWebBrowser
br = CefSharp.OffScreen.ChromiumWebBrowser();

Go by url 2 times:
br.Load(url)
await br.EvaluateScriptAsPromiseAsync(script);
br.Load(url)
await br.GetSourceAsync();
br.Load(url)

Fulfill JS
_browser.EvaluateScriptAsPromiseAsync(script)

Expected behavior

Fulfilling of JS

Actual behavior

JS Error Request BrowserId : 1 not found it's likely the browser is already closed

Regression?

After regression to version 108 problem dissapeared.

Known Workarounds

Likely problem is here
https://github.com/cefsharp/CefSharp/blob/master/CefSharp.BrowserSubprocess.Core/CefAppUnmanagedWrapper.cpp
Look at history..

Does this problem also occur in the CEF Sample Application

Yes using WPF/OffScreen command line args

Other information

No response

It seems that happening with only some Websites.
I enabled the CEF logging, maybe can you find here something.

cef.log

@amaitland

good day @amaitland
I did https://github.com/netmaxik/CefSharp.MinimalExample.netcore special.
Use WPF project and press Test button. On title you will see Elements under mouse. Press Test again to stop. After you go to : https://accounts.google.com/?hl=en, wait to load and press test again you see that error appears . For me last version where it was work correctly was : 112.3.0 After that i got that error everywhere.

@netmaxik

@netmaxik have you tried the new v121.3.x ? Has the issue been resolved @amaitland ?
I'm experiencing the same problem @netmaxik is, basically anything related to Google (google drive, docs, gmail, accounts, etc...) is broken on all versions past 112.3.0. Haven't tested v121.3.x though.

Add files via upload

Not sure if this was what I was supposed to do (I've never done this before), but I forked the entire master branch, changed the offscreen test cs file, included the part which causes an exception, and initialized pull request on this one single file from my fork: #4741

I could not get it to compile or run though, there was a whole bunch of errors in the C++ sources which I'm unfamiliar with, so I could not see if the test truly replicates the issue described here, but I did test it in async fashion as well in the original test I sent you, and it did produce the same exception, so hopefully you'll be able to replicate the issue on your end and see what's causing it in the first place, so we can get this resolved.

Thank you.

Adding test to replicate this issue: cefsharp#4621

Test - Add reproduction for issue 4621

@mitchcapper

@mitchcapper @yevklim Unfortunately cefSharp.postMessage seems to have the same problem for me.
I wrote this method:

private static Dictionary<string, EventHandler<JavascriptMessageReceivedEventArgs>> eventHandlers = new Dictionary<string, EventHandler<JavascriptMessageReceivedEventArgs>>();
 
public static async Task<T> EvaluateMessage<T>(this ChromiumWebBrowser browser, string script)
       {
           var tcs = new TaskCompletionSource<T>();
           Guid g = Guid.NewGuid();
           void Handler(object sender, JavascriptMessageReceivedEventArgs e)
           {
               try
               {
                   var response = e.ConvertMessageTo<OperationResult>();
                   eventHandlers.TryGetValue(g.ToString(), out EventHandler<JavascriptMessageReceivedEventArgs> _handler);
                   if (_handler == null)
                   {
                       return;
                   }
                   if (response.Operation == g.ToString() && response.Result != null)
                   {
                       eventHandlers.Remove(g.ToString());
                       tcs.SetResult((T)response.Result);
                       browser.JavascriptMessageReceived -= _handler;
                   }
               }
               catch (Exception ex)
               {
                   tcs.TrySetException(ex);
                   browser.JavascriptMessageReceived -= Handler;
               }
           }
           eventHandlers.Add(g.ToString(), Handler);
           browser.JavascriptMessageReceived += eventHandlers[g.ToString()];
           
           // JavaScript absenden
           browser.ExecuteScriptAsync($"cefSharp.postMessage({{ Operation: '{g}', Result: {script} }})");

           return await tcs.Task;
       }

After a redirect I receive no messages anymore. I even tried to store the handlers for getting an overview. The handlers before the redirect are removed, after a redirect they stay.

@yevklim I didn't found the method ExecuteJavaScriptAsync so I took ExecuteScriptAsync. I assume that you mean this method.

@mitchcapper @yevklim Unfortunately cefSharp.postMessage seems to have the same problem for me.

Are you actually getting the "Request BrowserId : 1 not found it's likely the browser is already closed" or do you just mean the post message does not work?

After a redirect does EvaluateMessage get fired? I assume given you mention the handlers are still in the dictionary. Just to confirm if you have a long running handler on JavascriptMessageReceived get called? Are there any javascript errors from running cefSharp.postMessage? (ie devtools)

Is there a specific easy site to use the above code on to reproduce?

Clearly, there are some very unfortunate bugs in either CEF or CefSharp at this point, which cause problems downstream. Besides the half-broken IPC that I described previously, my company encountered multiple app crashes caused by a null pointer somewhere in the Chromium source code.

Whilst I believe it would only be right to help the maintainers to resolve the issues, some people downstream simply don't have the time and resources for it, but do have the necessity of solving the problem sooner rather than later. Luckily, there are good alternatives, e.g., WebView2 from Microsoft. Some people may not like the fact that it's from Microsoft, but it is objectively more stable than CefSharp at this time.

My company was able to switch to WebView2 in a matter of days. It's not perfect, and it has its own issues, but nothing critical.

I'm writing this not to disrespect CefSharp, but to suggest a viable alternative for those who need it.

If you can't provide even the full code to a crash then it may be grasping at straws to try and debug. Most of the time if you are consuming CefSharp you are going to have someone on hand who has the technical knowledge to create a failing test case. You already created code that causes the crash, so it likely is just having someone slowly add that code to a test case to repro the crash in a simple form. When you are unwilling to do this as you dont want to spend the time/resources to do so you are saying the bug is not important enough for us to reduce it down to something easier for the developers to diagnose and instead they should spend their time doing it. It looks like you folks did find multiple work arounds though for this (and thanks of course for sharing those).

This bug has those work arounds along with some others stated and there have yet to be a repro-case showing they don't work. This is also tricky as while many problems may be fairly easy to pinpoint which side of the border they land on (being either a CefSharp issue or more commonly an upstream CEF issue) due to the somewhat unsupported nature of this bug for returned data in CEF it less clear.

It is understandable that consumers of this library may not have time or technical skill to figure out this bug. It is also understandable that some of these sorts of things could cause real problems for companies building solutions off CEF/CefSharp. If though you have a product that is important to business sponsoring CefSharp would seem like a great way to help ensure the product continues to function as you need it. If you have that necessity, if it is causing some real negative cost to the company the longer it stays unfixed then most of the time I would hope the company could invest in CefSharp not just to support it, but as an actual cost saving measure. Even with an internal tool, if you are losing lets say 10 man hours a month to this bug and paying employees $20-30 an hour then if funding this at $150 a month gets it resolved in 1 month instead of 4 that seems like a very worthwhile investment.

amaitland spends quite a bit of time on CefSharp and I would guess prioritizes issues that effect a larger portion of the user base, ones that have clear potential directions to be fixed, or ones of personal interest. This is aside from the fact that helping fund CefSharp allows him to spend more time on issues and he does try to make sure sponsors issues have priority as well as they are helping keep this project alive.

As for the frustration in bugs with CEF (as maybe your other crashes likely are) that is another can of worms. While clearly there is a team on chrome development as soon as you start to get away from the paths they use it for you can see bugs staying open there for years. As Cefsharp has largely had the policy of using the official builds even if a patch was created if it hasn't been accepted by upstream it is highly unlikely that would make it into CefSharp itself (other can through custom builds).

I doubt amaitland takes any offense to you moving to WebView2 he personally has worked contributing code around WebView2 including the cool WebView2.DevTools.Dom. Everyone has different use cases and if WebView2 is more reliable and does what you need that's great. CefSharp covers allows for a very deep and wide amount of control over chromium and has feature parity with many of the CEF possibilities (and sometimes exceeding those through helpers). WebView2 has a much smaller footprint and doesn't allow nearly the same level of control. MS does have a team of developers on WebView2 but there certainly are cases where bugs that are crippling for some use cases can be stagnant there for quite some time without any obvious progress. If you did decide something was critical enough for you to just solve it given WebView2 is closed source that isn't really an option.

@mitchcapper

Firstly a huge thank you to @mitchcapper for taking charge of this issue! Your contributions to the project over the years has been truly amazing and you'll forever have my gratitude! 🙏 Thank you!!!

Besides the half-broken IPC that I described previously,

With the BF Cache disabled I cannot reproduce any of the behaviors described. Hence the need for a failing test case. There are already some test cases that can be used as a basis. As programmers I'm sure you can appreciate that unless someone provides a reliable way to reproduce the issue then there isn't really anything that can be done.

I still believe this is a CEF issue and will need to be fixed upstream, that being said there's always a chance there is something that can be done to workaround the issue once it can be reproduced.

Having already spent a large number of hours trying to replicate and come up with workarounds for this issue, I'm not really inclined to invest any more time until someone can provide a failing test case (If any of the GitHub sponsors need help, then I'm happy to work with them directly).

Using the devtools API for javascript execution ie: https://github.com/cefsharp/CefSharp.Dom?tab=readme-ov-file#evaluate-javascript devtools does not seem to trigger the same crash given the alternate mechanism in which it works.

I've just released an updated version of CefSharp.Dom which is a viable alternative to using any of the EvaluateScript methods. There is a fairly extensive DOM API available, you can perform some fairly complex automation tasks with a strongly typed API.

await using var devtoolsContext = await chromiumWebBrowser.CreateDevToolsContextAsync();
var seven = await devtoolsContext.EvaluateExpressionAsync<int>("4 + 3");
var someObject = await devtoolsContext.EvaluateFunctionAsync<dynamic>("(value) => ({a: value})", 5);
Console.WriteLine(someObject.a);

//Strongly typed element types (this is only a subset of the types mapped)
var htmlDivElement = await devToolsContext.QuerySelectorAsync<HtmlDivElement>("#myDivElementId");
var htmlSpanElement = await devToolsContext.QuerySelectorAsync<HtmlSpanElement>("#mySpanElementId");
var htmlSelectElement = await devToolsContext.QuerySelectorAsync<HtmlSelectElement>("#mySelectElementId");
var htmlInputElement = await devToolsContext.QuerySelectorAsync<HtmlInputElement>("#myInputElementId");
var htmlFormElement = await devToolsContext.QuerySelectorAsync<HtmlFormElement>("#myFormElementId");
var htmlAnchorElement = await devToolsContext.QuerySelectorAsync<HtmlAnchorElement>("#myAnchorElementId");
var htmlImageElement = await devToolsContext.QuerySelectorAsync<HtmlImageElement>("#myImageElementId");
var htmlTextAreaElement = await devToolsContext.QuerySelectorAsync<HtmlImageElement>("#myTextAreaElementId");
var htmlButtonElement = await devToolsContext.QuerySelectorAsync<HtmlButtonElement>("#myButtonElementId");
var htmlParagraphElement = await devToolsContext.QuerySelectorAsync<HtmlParagraphElement>("#myParagraphElementId");
var htmlTableElement = await devToolsContext.QuerySelectorAsync<HtmlTableElement>("#myTableElementId");

My company was able to switch to WebView2 in a matter of days. It's not perfect, and it has its own issues, but nothing critical

I'd encourage everyone to take a look at the WebView2 issue tracker, looking at just the bugs.

https://github.com/MicrosoftEdge/WebView2Feedback/issues?q=is%3Aissue%20state%3Aopen%20label%3Abug

I want to make it clear that embedding Chromium as a browser control is a difficult task. Microsoft with a team of developers have their hands full just with bugs alone. Chromium isn't designed to be embedded, any making it work is no small feat.

CEF is open source, maintained by a very small team, the CEF maintainer (Marshall Greenblatt), started the project back in 2008, that's 17 years ago! Marshall deserves our praise and thanks for the amazing work!

Yes there maybe bugs from time to time, that's the ever changing nature of Chromium, a new major release every month, that's crazy!

I doubt amaitland takes any offense to you moving to WebView2 he personally has worked contributing code around WebView2 including the cool WebView2.DevTools.Dom. Everyone has different use cases and if WebView2 is more reliable and does what you need that's great.

When Microsoft launches a competing project, you have to be pragmatic about these things.

Some people may not like the fact that it's from Microsoft, but it is objectively more stable than CefSharp at this time.

Until they release a new version that has a critical bug, that automatically gets rolled out, all your clients are hence automatically upgraded and all of a sudden stop working!.

Once such example is MicrosoftEdge/WebView2Feedback#3029

This was a whole ago, I believe there have been a few instances of similar issues relatively recently. So be very aware, you are handing control over to someone else when it comes to your browser updates!

For customers with stability requirements, this issue is quite serious. The idea of addressing it from a caching perspective is a good approach. Perhaps I should roll back to version 112.3.0 first. Thank you, everyone.

WinForms/WPF/OffScreen - Disable back forward cache to improve javasc…

In M139 I'm going to disable Back forwards cache by default. It's not clear that people having this issue are actually implementing that workaround.

If after upgrading to M139 you can still reproduce the issue then you need to provide a clear means of reliably reproducing the problem. Until someone steps up to help out it's unlikely this will be resolved.

Has anyone testing in M139 or greater and still experiencing the issue?

Good day!! Yes still same problem at https://search.google.com/ even worse, as before I can create new window and its works not its not fix like that

…

On Fri, Oct 24, 2025 at 8:28 PM Alex Maitland ***@***.***> wrote: *amaitland* left a comment (cefsharp/CefSharp#4621) <#4621 (comment)> Has anyone testing in M139 or greater and still experiencing the issue? — Reply to this email directly, view it on GitHub <#4621 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AFUMWKJQ6XO5W2UESYZG2HT3ZH5NDAVCNFSM6AAAAAA6ZJMBUKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTINBSGQYDMOBRGQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>

Tests - Simplify ShouldFailWhenIsObjectCachedCalledWithInvalidObjectName

Forum thread https://www.magpcss.org/ceforum/viewtopic.php?f=6&t=20428

OnBrowserDestroyed was no longer reliable, code has been rewritten #5197

The check that produced the error reported above no longer exists.

Navigation Menu

Repository navigation

Error while fulfilling of JS: Request BrowserId : 1 not found it's likely the browser is already closed #4621

Is there an existing issue for this?

CefSharp Version

Operating System

Architecture

.Net Version

Implementation

Reproduction Steps

Expected behavior

Actual behavior

Regression?

Known Workarounds

Does this problem also occur in the CEF Sample Application

Other information

57 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Error while fulfilling of JS: Request BrowserId : 1 not found it's likely the browser is already closed #4621

Description

Is there an existing issue for this?

CefSharp Version

Operating System

Architecture

.Net Version

Implementation

Reproduction Steps

Expected behavior

Actual behavior

Regression?

Known Workarounds

Does this problem also occur in the CEF Sample Application

Other information

Activity

amaitland commented on Nov 1, 2023

CloudMak commented on Nov 2, 2023

amaitland commented on Nov 2, 2023

amaitland commented on Nov 9, 2023

daveime68 commented on Dec 14, 2023

ficho-hun commented on Jan 9, 2024

netmaxik commented on Feb 1, 2024

nebojsasandin commented on Feb 23, 2024

amaitland commented on Feb 24, 2024

nebojsasandin commented on Feb 29, 2024

amaitland commented on Mar 2, 2024

nebojsasandin commented on Mar 3, 2024

57 remaining items

pop1989bb commented on May 25, 2025

mitchcapper commented on May 26, 2025

yevklim commented on Jun 19, 2025

mitchcapper commented on Jun 20, 2025

amaitland commented on Jun 21, 2025

tomoyii commented on Aug 1, 2025

amaitland commented on Aug 17, 2025

amaitland commented on Oct 24, 2025

netmaxik commented on Nov 4, 2025

amaitland commented on Dec 12, 2025

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions