Losing access to bound object

[mstrattonHarris]

Is there an existing issue for this?

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

CefSharp Version

126.2.180.0

Operating System

Windows 10

Architecture

x86

.Net Version

Net 4.8

Implementation

WinForms

Reproduction Steps

We have bound to the CefSharp browser using the sync "bound" object and everything works fine until the page has been idle for about 20 minutes. Then any access to the bound object fails and we have to force the browser to close without performing a save. I have searched high an low on how to prevent the "bound" object from being lost over long periods of time.

i have tried modifying IIS to have no timeouts, i have tried writing a "keepAlive" javascript call taht will go the server and pull down a json file and have been fighting this time out regardless of implementing it through sync or async calls.

The web page I am rendering is a 3rd party web page and it launches dialogs in our C# application when needing to create new information to be included on the page.

I dont have a way to provide you with a sample with all of the things involved but what i can say is we do the following:

/////////// I DECLARE IT WITH LegacyBindingEnabled - was seeing CefSharp.BrowserSubprocess error and this fixed it //////////
_browser = new ChromiumWebBrowser(_url)
{
Dock = DockStyle.Fill
};
_browser.JavascriptObjectRepository.Settings.LegacyBindingEnabled = true;

///////////////// I BIND IT WITH OUR CUSTOM OBJECT ///////////////////////

    if (_boundObject != null)
        {
            boundBrowser = new CustomBoundObject(_browser);
            _browser.JavascriptObjectRepository.Register("bound", _boundObject, false);
        }

/////////// I CAN CONFIRM IT BINDS ///////////////////

        _browser.JavascriptObjectRepository.ObjectBoundInJavascript += (sndr, evt) =>
        {
            _bObjectBounded = true;
            var name = evt.ObjectName;
            System.Diagnostics.Debug.WriteLine($"Object {name} was bound successfully.");
        };

All calls are good until what i suspect is a timeout occurs. I set IIS to 0 for timeout to make it indefinite and that did not help.

Expected behavior

I expect the bound object to be present.

Actual behavior

Bound object is present until time passes and then in dev tools, i set a break point where we will first access the bound object. In the watch window, it is still showing as an object until i invoke the call and then it goes to undefined.

Regression?

We upgraded from version 73.1.30 to 126.2.180. Original implementation I did not discover the IJavascritpCallback steps i needed to do and I implemented my changes asynchronously. That also lost its binding over time

Known Workarounds

None

Does this problem also occur in the CEF Sample Application

Not Tested

Other information

No response

[mstrattonHarris]

I will add that this is the exception i think i am getting: System.IO.PipeException: 'There was an error reading from the pipe: The pipe has been ended. (109, 0x6d).'

[amaitland]

What version are you using? Please only open an issue if you can reproduce the problem with version 130.1.90 or later.

As per https://github.com/cefsharp/CefSharp/blob/master/.github/ISSUE_TEMPLATE/bug_report.yml

CefSharp Version
126.2.180.0

Does your problem reproduce with the current supported version? M131 at time of writing.

[mstrattonHarris]

Hello Alex, Thank you for the response over the weekend. Our situation was a unique one where I came onto an already existing project about 3 years ago that was in “maintenance mode”. Since then, we have been revitalizing it and moving it forward to support our existing customers. The problem we had is exemplified because this application began in 1997 and has grown with a mix of developers and solutions over time. The update to CefSharp began when the latest version WAS 126.2.180.0 and we began going down that path because our browser was so out of date, other services were rejecting calls from our application. The update to the latest version did address our security issues but it introduced a new problem with an existing third party web service we use. That web service runs on our server and to summarize what it does: 1. C# binds to the web browser 2. Interaction on the web browser calls back into the bound object 3. The bound object loads and invokes calls on ANOTHER dll to execute a command (this is where I think the pipe issue originates) 4. That then calls back to the UI thread to launch a C# dialog within our application While that is not all of it, the amount of jumping around in the C# side left the web service in a state where it either went to a white screen (sync design) or “looked” like it worked but would not close or really “do” anything when interacting with the C# related work. I feel that this background is needed for you to understand that this is NOT a problem that any modern application should have. The application architecture has seen many developers over the years and it shows from old school DLL best practices, COM implementations, WPF and XAML. The good news is we got it working to a point where the web page will not launch a new C# dialog but we can still save its current state allowing us to close and reopen the web page with a new instance of our BrowserForm dialog. To achieve this, we ultimately used the Cef.DoMessageLoopWork along with making the web page async and calling a synchronous call in the bound object. It is really a complex solution I have been tasked with revitalizing. Thank you again for your reply over the weekend. Over the past 3 months of work my googling had me finding the pattern of YOU responding more often than not both within your official website and in places like Stack Overflow. Your dedication to your software shows. Have a wonderful holiday, Matt Stratton From: Alex Maitland ***@***.***> Sent: Saturday, December 21, 2024 5:35 PM To: cefsharp/CefSharp ***@***.***> Cc: Matthew Stratton ***@***.***>; Author ***@***.***> Subject: [EXTERNAL] Re: [cefsharp/CefSharp] Losing access to bound object (Issue #5011) CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. What version are you using? Please only open an issue if you can reproduce the problem with version 130.1.90 or later. As per https://github.com/cefsharp/CefSharp/blob/master/.github/ISSUE_TEMPLATE/bug_report.yml<https://urldefense.com/v3/__https:/github.com/cefsharp/CefSharp/blob/master/.github/ISSUE_TEMPLATE/bug_report.yml__;!!HzYX23eHnp2Wbe4!QNnzlh1-Y_r5PU80TlRuCFpDBcsKMg7I66Jl17cSTsaNPiDw4f8scJVYFyEOxdhLzUtV3aR9V2B-Ch502GkLeAb8dggaPA$> CefSharp Version 126.2.180.0 Does your problem reproduce with the current supported version? M131 at time of writing. — Reply to this email directly, view it on GitHub<https://urldefense.com/v3/__https:/github.com/cefsharp/CefSharp/issues/5011*issuecomment-2558257764__;Iw!!HzYX23eHnp2Wbe4!QNnzlh1-Y_r5PU80TlRuCFpDBcsKMg7I66Jl17cSTsaNPiDw4f8scJVYFyEOxdhLzUtV3aR9V2B-Ch502GkLeAbk9UtWQA$>, or unsubscribe<https://urldefense.com/v3/__https:/github.com/notifications/unsubscribe-auth/AXIJEKN4BT7TUQEDPHDFYAL2GXUINAVCNFSM6AAAAABT3HEVFOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKNJYGI2TONZWGQ__;!!HzYX23eHnp2Wbe4!QNnzlh1-Y_r5PU80TlRuCFpDBcsKMg7I66Jl17cSTsaNPiDw4f8scJVYFyEOxdhLzUtV3aR9V2B-Ch502GkLeAae94-CLg$>. You are receiving this because you authored the thread.Message ID: ***@***.******@***.***>>

[amaitland]

Firstly thank you for the kind words!

Apologies on the delay, just getting back on top of things after being on holiday for a few weeks over Christmas.

I feel that this background is needed for you to understand that this is NOT a problem that any modern application should have. The application architecture has seen many developers over the years and it shows from old school DLL best practices, COM implementations, WPF and XAML.

Sounds like you are in for an interesting challenge! 😄 I can relate having worked on an application that's evolved greatly over the past decade!

The good news is we got it working to a point where the web page will not launch a new C# dialog but we can still save its current state allowing us to close and reopen the web page with a new instance of our BrowserForm dialog. To achieve this, we ultimately used the Cef.DoMessageLoopWork along with making the web page async and calling a synchronous call in the bound object.

Just to clarify are you still having an issue with losing access to the bound object?

M126 was the first version to switch over to using the Chrome Bootstrap. If you are still having problems you could try switching back to the Alloy bootstrap (which was removed upstream in M128).

#4835 (comment)