Javascript Binding - Store JavascriptObjects/Settings per CefBrowser

[amaitland]

Currently gcroot<Dictionary<String^, JavascriptObject^>^> _javascriptObjects; is stored per sub process, when multiple browsers share the same sub process this limits the flexibility somewhat.

Look at storing the objects at a per browser level.

[amaitland]

https://github.com/cefsharp/CefSharp/blob/master/CefSharp.BrowserSubprocess.Core/CefAppUnmanagedWrapper.h#L33

This change would maybe allow for limiting the number of sub processes to 1 (would have to test to be sure).

[amaitland]

Legacy binding will require the objects to be bound at the process level for popups to function.

[amaitland]

Might be worth making this configurable, keeping the current behavior.

[amaitland]

LegacyBinding with multiple ChromiumWebBrowser instances that share the same render process and use the same bound object names require this level of separation, details in #2301

[jsoldi]

Would this also solve the bound object disappearing when navigating to another domain when using legacy binding?

[amaitland]

@jsoldi no, totally unrelated.

[amaitland]

Revert process model change in 38934a1 when this is implemented.

[Termit1975]

We're migrating from 37, I'm willing to implement this fix like I did with @sylvain-hamel implementing PR: #536.
I suspect it will be fairly the same work. Any hint or considerations you have in mind that I should know of?

Thanks

[amaitland]

@Termit1975 What exactly is your use case? You can use a separate RequestContext for each browser to force isolation, you can have RequestContext's share the same cache.

The chromium process model has changed dramatically since this was originally opened see https://www.chromium.org/Home/chromium-security/site-isolation

We'd need a fairly extensive set of integration tests to accompany any PR for it to be considered for merging.

[ebelanger]

Greetings @amaitland,

I am a collegue of @Termit1975 and I'll be taking over. We tried the separate RequestContext approach but this causes the creation of a new render process on each browser instantiation. In our case, we need to limit the number of render processes being used to have smaller memory footprint for our clients.

We did some tests while limiting the number of render processes on the sample application JS binding test page. When set to a limit of 2, the first test page would work but the second would just hang and this seems to be the same behavior we see in our application.

Would you consider the JS binding test page a valid set of integration tests?

[amaitland]

@ebelanger Can you please elaborate on the specifics of your use case. How many browsers are you using, are they different origins

Is there a reason you cannot use the newer binding method? In a lot of cases it's very easy to inject some javascript upon V8Context creation that starts initiates binding and minimal other changes are required.

In our case, we need to limit the number of render processes being used to have smaller memory footprint for our clients.

Assuming you are referring to the renderer-process-limit command line arg. Technically this isn't a supported option, I have seen at least one other report of problems https://magpcss.org/ceforum/viewtopic.php?f=6&t=17346

It's very unlikely any bugs you experience when using this option would be fixed in CEF/Chromium. If you haven't already then I'd suggest doing some further research in the broader Chromium/CEF context to determine if there are any other reported issues.

We did some tests while limiting the number of render processes on the sample application JS binding test page. When set to a limit of 2, the first test page would work but the second would just hang and this seems to be the same behavior we see in our application.

Can you please provide additional details, exact changes to the code and steps to reproduce this.

Did you debug the renderer process and confirm the issue you are seeing is actually related to this particular issue?

Would you consider the JS binding test page a valid set of integration tests?

By itself no. We'll need some automated tests that cover the different scenarios, newer binding, legacy binding, popups, cross origin navigations.

To set a realistic set of expectations here it would likely be months before a PR made it into a Release branch.

[ebelanger]

@amaitland

Can you please elaborate on the specifics of your use case. How many browsers are you using, are they different origins

The browser instances used in our application are of the same origin except in rare cases; with no external navigation. There's potentially an unlimited number. We could consider them like tabs in Chrome.

Is there a reason you cannot use the newer binding method?

We are now using Javascript Binding v2 instead of the legacy API if this is what you are referring to.

Can you please provide additional details, exact changes to the code and steps to reproduce this.

• Modify CefSharp.WinForms.Example/Program.cs CefSettings to add renderer-process-limit of 2.
• Start the application
• Open the JS Binding test page
• Keep opening new tabs for the JS Binding test page until it doesn't work
• This test works when there is no renderer-process-limit

Did you debug the renderer process and confirm the issue you are seeing is actually related to this particular issue?

I did not debug CefSharp code yet but it's on my list of things to do. From the debugging I did, I could see that the binding object was present in the browser and that the call was made but it never triggered our code, thus making the conclusion it was between CEF or CefSharp at this point. This issue seemed most relevent and since RequestContext fixed the bug by introducing one renderer process per browser instance, we decided to seek help at this point.

If there are alternative methods or avenues we might try, I am open to suggestions and trying them out.

[amaitland]

@ebelanger Thanks for the clarification 👍

The browser instances used in our application are of the same origin except in rare cases; with no external navigation. There's potentially an unlimited number. We could consider them like tabs in Chrome.

If they are in the same origin then they should by default already share the same render process. Under what scenario are you seeing additional render processes spawned?

Please make sure you've read https://bitbucket.org/chromiumembedded/cef/issues/2498/add-support-for-site-per-process

With site-per-process enabled a spare renderer process will be created for use with a future browser or navigation.

As per https://bitbucket.org/chromiumembedded/cef/issues/2498/add-support-for-site-per-process#comment-54186905

You should be able to disable the spare render process using the following command line arg.

--disable-features=SpareRendererForSitePerProcess

• Modify CefSharp.WinForms.Example/Program.cs CefSettings to add renderer-process-limit of 2.

If you skip this step then does it behave as expected? Are you seeing additional render processes created?

Versions of CefSharp prior to 63 relied on process-per-tab for javascript binding, this forced a render process per ChromiumWebBrowser instance. This is no longer the case, the default Site Isolation model is used, same origin websites should share the same domain. Are you basing your assumption that you need to limit the render processes on past experience or current observation?

your sample simply by moving the two private field

@Termit1975 I have no idea what you mean by this. Please provide context/link etc