Hi,

There was an issue with JSExtInvoke EO.WebBrowser.dll 3.0.55, which we have updated to 3.0.56 this morning. However we are not aware of any issue with 3.0.54. But in any case you can update to 3.0.56 and see if the problem still occurs.

The most common scenario that can make extInvoke to fail is JavaScript re-entry. JavaScript engine can not be re-entered. However the ability to call into .NET code from JavaScript code makes it possible for you to call JavaScript code again from your .NET side code. In this case the JavaScript call from your .NET side code will fail because it would cause re-entry for the JavaScript engine.

Thanks!

Hum...that's interesting. The reason that JavaScript engine can not be re-entered has to do with the design of the JavaScript language. It should not have anything to do with the browser. For example, if you have the following JavaScript code:



Then the JavaScript language guarantees that variable x will still have value 1 by the time alert("hi") returns, this means that it is not allowed for function alert to call either directly or indirectly to any other JavaScript code. If this were allowed, then it would be possible for that JavaScript code to alter variable x's value, which would break the previous rule that x will still have value 1 by the time alert returns.

In our case, alert can call into .NET code. So if you have the following call chain:

alert -> your .NET code -> someOtherJSFunction

The we will fail someOtherJSFunction on purpose in order to guarantee that you won't get a chance to modify variable x. So it's not a technical limitation that the engine can not be re-entered. It is specifically designed this way on purpose.

Hope this makes sense to you.

Thanks!

Hi,

That's a very interesting observation. IE's implementation will definitely cause the unexpected result of variable x being modified during alert, this is something we think is wrong but we will investigate further to see what we can find. It could be that our understanding is wrong. In that case we will remove the purposely set up blocks to allow re-entering if this proves to work fine with Chrome's script engine.

As to GetDOMWindow, this has to do with our internal implementation. Internally GetDOMWindow calls EvalScript. This can be optimized as calling the underlying DOM object directly. Since in the current implementation it uses EvalScript, it does raise the re-entering exception. After we optimize this part it should no longer be an issue.

Thanks!

Hi,

We have posted a new build that enabled re-entering on some cases -- specifically re-entering is allowed from within custom dialog handler or JSExtInvoke handler. As such it is possible for you to have the following call flow just as an example:

1. .NET side calls WebView.EvalScript("someExtensionFunction('foo');");
2. This calls into the JavaScript engine, assume "someExtensionFunction" is a function implemented on the .NET side, this calls back to the WebView's JSExtInvoke handler, or the handler for that function if the function was registered with RegisterJSExtensionFunction;
3. Inside the handler, the code calls WebView.EvalScript("alert('bar');");
4. This calls into the JavaScript engine again, and triggers the WebView's JSDialog event;
5. Inside the JSDialog event's event handler, the code calls WebView.EvalScript("document.URL") to get the current Url;

Here the JavaScript engine is re-entered twice at step 3 and step 5. Our test did not reveal any problem with Chrome's JavaScript engine for such cases.

The EO.WebBrowser.dll version for this build is 3.0.59.0. Please take a look and let us know how it goes.

Thanks!

Hi,

EvalScript is still purposely blocked in a few other event handlers. For example, one of such event is BeforeNavigate. Consider the following sequence:

1. Your code call EvalScript("window.location.href=new_url;");
2. This triggers BeforeNavigate and calls back to the .NET side;
3. If you call EvalScript again inside the BeforeNavigate handler, you will receive an error (This is the same error as the "re-entry" error you had before but we now use a different error message);

The reason that is still blocked is because we have not fully tested all scenarios/code paths for these cases yet. In the above case. Step 1 actually does not wait until the new page is loaded, so by the time step 2 is called, step 1 may or may not have finished, which raises potential race conditions if we were to allow step 3 to proceed. This is something that has not been fully tested. Consider the fact that BeforeNavigate is mainly for user to determine whether the navigation should proceed, we think it might not be a huge restriction to block EvalScript inside this handler. As such the block inside this handler remains.

Thanks!

Hi,

The recommended way to run JavaScript is to use QueueScriptCall. EvalScript is synchronous and convenient but there is a race condition that occurs and cause value of CanEvalScript to change from true to false right after you checked the value and before you call EvalScript. So it is not a reliable way. QueueScriptCall resolves this issue by waiting for it become safe to evaluate script code and then run the code and calls a callback you provided after it is done. So it is asynchronous but reliable.

Thanks!

Just to highlight what we have discussed 2 years ago and EO has acknowledge that javascript re-entry should be ok except for the following sequence, as also explained:

EvalScript is still purposely blocked in a few other event handlers. For example, one of such event is BeforeNavigate. Consider the following sequence:

1. Your code call EvalScript("window.location.href=new_url;");
2. This triggers BeforeNavigate and calls back to the .NET side;
3. If you call EvalScript again inside the BeforeNavigate handler, you will receive an error (This is the same error as the "re-entry" error you had before but we now use a different error message);