Javascript Bound objects no longer registered after cross-site navigation

[MIvoylov]

When you call the method named "LoadUrl" losted all registered JsObject.

What I do:

1. Create a browser: new ChromiumWebBrowser (null).
2. Registering JsObject .: browser.RegisterAsyncJsObject
3. Call the method LoadUrl. Registered object "JsObject" available on the page.
4. The method LoadUrl is called again with a different address. On the loaded page registered object "JsObject" is not available

How can re-register JsObject or prevent registserd objects clean?

[cefsharp-ms]

I did a few experiments, but it seems like the new render process won't receive the messages sent to PID_RENDERER until the old one closes + some time (I actually found a thread describing something like this: http://www.magpcss.org/ceforum/viewtopic.php?f=6&t=10573&p=16293&hilit=domain+new+render+process#p16293). This usually means that the context is already created when messages are starting to get through to the new render process 😞 ...it still seems like the only stable point in time to transmit things is the callback where extensions are getting forwarded.

[amaitland]

Added --process-per-tab as a temp workaround, will release a new -pre shortly and see if there's any feedback.

5676672

[cefsharp-ms]

I'm testing --process-per-tab for a while now and it seems to solve this for regular browser instances. However the new context for the popups are created before the OnRenderViewReady is called, so the bound objects are unavailable in the custom popups.

[amaitland]

However the new context for the popups are created before the OnRenderViewReady is called, so the bound objects are unavailable in the custom popups.

Thanks for the heads up 👍

[amaitland]

Interesting background read can be found at http://magpcss.org/ceforum/viewtopic.php?f=6&t=13386&sid=cf4881bba36a72c96ca7de0e891391de#p27469

May not be practical in a CefSharp sense, will need to investigate further.

[amaitland]

The solution of using --process-per-tab has served us well until now, it appears that it's broken in Chromium. in the 3029 branch. As we're not actually generating a release using this branch, it's not too big a concern. If the problem persists in 3071 then we'll need to come up with another solution.

https://bitbucket.org/chromiumembedded/cef/issues/2163/process-per-tab-no-longer-works

[amaitland]

I've removed quite a few of the old comments. If your comment has been deleted it's nothing personal, just keeping the size of the overall issue down.

Now to clarify a few points, the problem still exists any the latest 63.0.0-pre01 release (3239 branch)

will --renderer-process-limit=1 not help?

@jogibear9988 With code changes it could be made to work, the current implementation does not support that scenario, see #2142

In CEF Python I do javascript bindings:

After browser is created sending IPC message
In renderer process every time OnContextCreated is being called

Seems to be working fine.

@cztomczak This solution would appear to be workable in version 62 and below, unfortunately I'm seeing problems with IPC messaging being sent from OnContextCreated after a render process switch, see http://magpcss.org/ceforum/viewtopic.php?f=6&t=15677 for details. I'd be curious to hear feedback from your testing with the 3239 branch.

The cefclient sample also has a binding test that seems to work ok if I understand correctly.

@japj cefclient does indeed have it's own binding feature, you can see https://bitbucket.org/chromiumembedded/cef/src/master/include/wrapper/cef_message_router.h?at=master&fileviewer=file-view-default#cef_message_router.h-59 for an example of it's usage. In my opinion it's very limited and not worth implementing.

[amaitland]

I do have an alpha version of what I believe to be a workable solution. I will post more information when I've received feedback.

[cztomczak]

@amaitland

In CEF Python I do javascript bindings:

1. After browser is created I am sending IPC message from browser process to renderer process. That IPC message contains js bindings and a copy of them is saved for later re-binding in step 2. I create browser synchronously and send js bindings after browser is created, so there may be some delay before js bindings are available, however haven't noticed any issue, in practice browser is still loading after being created.

2. In renderer process every time OnContextCreated is being called I re-bind js bindings using a copy of data sent in step 1. The data is already available for me to expose it in javascript (or will be available in a moment as it is already being sent in step 1), I don't have to send IPC message from renderer to browser process at this point to get them - as what you described is an issue in v63.

3. If user modifies js bindings in browser process I send another IPC message as in step 1.

[amaitland]

After browser is created I am sending IPC message from browser process to renderer process. That IPC message contains js bindings and a copy of them is saved for later re-binding in step 2. I create browser synchronously and send js bindings after browser is created, so there may be some delay before js bindings are available, however haven't noticed any issue, in practice browser is still loading after being created.

@cztomczak Have you tested with the 3239 branch? When the cross-origin switch occurs I'm seeing messages go missing or sent to the incorrect (old) render process. I've looked at your code and I'd be surprised if you didn't have exactly the same problem, at least with the 3239 branch. Soon as the cross-origin switch occurs the IPC messages aren't delivered reliably.

In renderer process every time OnContextCreated is being called I re-bind js bindings using a copy of data sent in step 1. The data is already available for me to expose it in javascript (or will be available in a moment as it is already being sent in step 1), I don't have to send IPC message from renderer to browser process at this point to get them - as what you described is an issue in v63.

That's what CefSharp did previously, data was sent in OnRenderViewReady, as there was only one render process per browser instance, this was reliable for almost all cases (there is a problem with popups reported above)

Thanks for taking the time to respond 😄

[cztomczak]

No, I haven't yet tested 3239 branch and neither "cross-origin" switch. I haven't had previously the need to expose js bindings to different addresses loaded in browser, so yeah looks like it would be an issue in cefpython, as this would create new renderer processes. However user can always manually rebind js bindings by calling Rebind() func if he knows an address changed (he can using OnBeforeBrowse or similar).

[cztomczak]

Looks like I've discovered an issue in cefpython, reported (cztomczak/cefpython#406) and referenced the three comments above, so please don't delete them :)

[amaitland]

However user can always manually rebind js bindings by calling Rebind() func if he knows an address changed (he can using OnBeforeBrowse or similar).

I tried OnBeforeBrowser and OnBeforeResourceLoad, was unable to get either of them reliably working in the cross-origin switch scenario. I'm basically seeing the same problem as outlined in https://bitbucket.org/chromiumembedded/cef/issues/929#comment-16412458 which I know is very old and marked as wontfix, I was able to reliably reproduce the problem last time I tested.

so please don't delete them :)

Understood 😄

[amaitland]

See #2246 for details on the new option for binding objects.

[amaitland]

The changes in #2246 have been published as part of the 63.0.0-pre02 packages which are now on Nuget.org.

[cefsharp-ms]

Just as an addition to this, I submitted a PR towards CEF: https://bitbucket.org/chromiumembedded/cef/pull-requests/147/allow-synchronously-sending-extra_info-to/diff
If/when this is merged, it could be used to transmit bound objects in a sync way.

[amaitland]

63.0.0 has now been released, see #2246 for details on the new Javascript Binding implementation.