|
|
Rank: Advanced Member
Groups: Member
Joined: 3/11/2014
Posts: 57
|
I'm invoking a c# function from javascript via extInvoke and it works swell.
Except if I set e.ReturnValue = true, i get undefined as the result in the JS.
Numbers work, so i can do x ? 1 : 0 kind of thing, but shouldn't bools serialize to the JS side as true/false?
I see that true/false values passed passed in to the function as arguments do come across properly.
Just seems to be a problem with the ReturnValue.
Am i missing something?
|
|
Rank: Administration
Groups: Administration
Joined: 5/27/2007
Posts: 24,196
|
Hi,
We have confirmed this to be a bug. This will be fixed with our next build, which should be available next week.
Thanks!
|
|
Rank: Advanced Member
Groups: Member
Joined: 3/11/2014
Posts: 57
|
Just updated to the latest version of the WebBrowser dll 3.0.57.0 in order to test this (coming from 3.0.45.0)
First the good news. This release does seem to correct the problem with returning a bool value via extInvoke, and extInvoke appears to still work.
But, the really really bad news is the EvalScript method appears to be totally broken.
I was using it, per your samples, to do something like so:
var f = (JSFunction)_EObrowser.WebView.EvalScript("$.my.someFunction", true);
f.Invoke(f, new object[] { result, new string[] { "a", "b", "c" } });
where $.my.someFunction is a function member of an object $.my that lives in the javascript side.
This was working in 3.0.45 (more or less, it wasn't passing the result parameter correctly, because it is a bool, i was expecting that would be fixed now).
But, with 3.0.57, my EvalScript call always throws an exception "EvalScript failed because channel is invalid."
A little further testing show that I get the same thing when doing:
var f = (JSFunction)_EObrowser.WebView.EvalScript("window");
var f = (JSFunction)_EObrowser.WebView.EvalScript("alert");
as shown in your documentation in the "Executing JavaScript Code" section.
Then, I tried your sample TabbedBrowser application, and when typing anything into the console pane, it throws that same exception.
Sorry to be grumpy, but this is pretty disappointing.
|
|
Rank: Administration
Groups: Administration
Joined: 5/27/2007
Posts: 24,196
|
Hi,
I sincerely apologize for the problem. We have posted a new build that should fix this issue. Please download it from our download page and let us know how it goes. This build contains EO.WebBrowser.dll 3.0.58.
Thanks!
|
|
Rank: Advanced Member
Groups: Member
Joined: 3/11/2014
Posts: 57
|
Yep, that works as expected now, and even fixes the bool arg problem.
Good.
I am a little concerned about your process here. Do you guys just push out a "nightly build" every day, every time something is delivered, once a week, or what? And what sort of QA goes into it. There should be log of changes for each build, where is that? The "what's new" page in the documentation is useless.
Basically, how am i supposed to trust that while this issue is fixed for today, that some other issue hasn't crept back in? I'd feel better if releases were less frequent, fully annotated (changelog), and better tested.
|
|
Rank: Administration
Groups: Administration
Joined: 5/27/2007
Posts: 24,196
|
Hi,
Yes. I understand your concern. We do post updates often but the "regular" builds do went through a whole process. However sometimes mistake does happen and in that case we do emergency builds and those builds do not go through the whole process. In this case it was a single line of code change but obviously the issue was seriously enough that requires to be corrected immediately. So we only tested the change on this build.
Internally we do have a full set of SCM tools and we have internal logs on all the changes. However those are more for developers/testers instead of for end users. We compile those changes regularly and "translate" them into end user understandable languages and post them in our announcement forum. Note that this is not the same as "What's new" section. The former is more of a technical change log, the later is intend to provide a much higher level of overview.
In any case, we understand the importance of the QA process and as a vendor your concern is our concern, and obviously there are always a lot of room of improvements. We appreciate your feedback very much and will strive to do better every day.
Thanks!
|
|
Rank: Advanced Member
Groups: Member
Joined: 3/11/2014
Posts: 57
|
Well, i've got some more bad news for ya...
There appears to be another subtle change between version 45 and 58.
I'm seeing that when a WebBrowser control is created (wpf in my case) there is an additional WorkerThread that is created now that didn't used to be there in version 45. And, apparently, this worker thread is not set as a background thread because when my process tries to exit, this thread is keeping it alive so it can't exit.
This is definitely a change from the behavior from build 45.
Now, I must add that this extra thread only seems to be a problem when my process happens to be Excel. (i have 2 applications host EO browsers, one is a WPF app, one is Excel using a VSTO addin that is hosting EO in a win forms ElementHost).
Still, it is a change in behavior within the past few builds. In both builds, i have an "EO.WebBrowser IO Thread". In build 58, I also see this extra "WorkerThread" in there. It appears to be a single thread per process (not per browser object).
At the time when my process is exiting, that thread's call stack is like so:
> EO.WebBrowser.dll!EO.WebBrowser.Internal.am.a(object A_0) + 0x7f0 bytes
mscorlib.dll!System.Threading.QueueUserWorkItemCallback.WaitCallback_Context(object state) + 0x3e bytes
mscorlib.dll!System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext executionContext, System.Threading.ContextCallback callback, object state, bool preserveSyncCtx) + 0xa7 bytes
mscorlib.dll!System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext executionContext, System.Threading.ContextCallback callback, object state, bool preserveSyncCtx) + 0x16 bytes
mscorlib.dll!System.Threading.QueueUserWorkItemCallback.System.Threading.IThreadPoolWorkItem.ExecuteWorkItem() + 0x60 bytes
mscorlib.dll!System.Threading.ThreadPoolWorkQueue.Dispatch() + 0x149 bytes
mscorlib.dll!System.Threading._ThreadPoolWaitCallback.PerformWaitCallback() + 0x5 bytes
[Native to Managed Transition]
[Appdomain Transition]
[Native to Managed Transition]
Can you confirm whether this is an intentional change or incidental side effect that can be fixed?
Thanks.
|
|
Rank: Administration
Groups: Administration
Joined: 5/27/2007
Posts: 24,196
|
Hi,
This is not an incidental side effect. It was added on purpose and it is a thread pool callback, not a dedicated thread. The purpose of the callback is to provide an OS handle monitor services to monitor certain handles. Since it is a thread pool, it is always run by background threads. Thus we did not notice any problem during our test.
It is very easy for us to monitor AppDomain.DomainUnload event and then signal the thread to exit. However it does puzzle us why it wouldn't exit by itself in Excel. We will research further and see if we can find anything on this. In any case, we will add the code to handle AppDomain.DomainUnload to siginal the callback to exit as a safety measure.
Thanks!
|
|
Rank: Advanced Member
Groups: Member
Joined: 3/11/2014
Posts: 57
|
Ok, thanks for the confirmation.
It is not totally surprising to me that you don't notice the problem within excel. Our use of it is somewhat atypical, to say the least.
I'm not 100% sure that an AppDomain unloaded hook will do the right thing here (there are 2 app domains in play in our excel environment and this causes some issues with some interop scenarios) but I'll give it a try as soon as that is available.
Sounds like you can do that pretty quickly.
Alternatively, would it be possible to get an API method that I could use to signal this thread that it is time to exit? I'd be fine with that.
I'll have to rollback to version 45 until this is resolved, so i'll be waiting for the next patch...
Thanks.
|
|
Rank: Administration
Groups: Administration
Joined: 5/27/2007
Posts: 24,196
|
Hi,
This is just to let you know that we have posted a new build with the following changes:
1. Handle AppDomain.DomainUnload event and trigger the callback to return immediately;
2. Added EO.WebBrowser.Runtime.Shutdown to shutdown everything and trigger the callback to exit;
You can try it and see if the automatic shutdown works fine for you. If not, you can try to call Runtime.Shutdown explicitly. Please let us know if it works for you.
Thanks!
|
|
Rank: Advanced Member
Groups: Member
Joined: 3/11/2014
Posts: 57
|
That seems to do the trick.
The AppDomain.DomainUnloaded approach seems to have worked, so I haven't tried calling the Shutdown method yet, but i appreciate you providing it, just in case.
Thanks.
|
|
Rank: Administration
Groups: Administration
Joined: 5/27/2007
Posts: 24,196
|
Great. Glad to hear that it's working for you. Please feel free to let us know if there is anything else.
|
|
Rank: Advanced Member
Groups: Member
Joined: 3/11/2014
Posts: 57
|
Well, dang it, there is more to the story.
On some of our machines, not all, we are now getting an unhandled exception when shutting down:
System.AppDomainUnloadedException was unhandled
Message: Attempted to access an unloaded AppDomain.
And that is all the info that I get when it occurs.
(one problem environment is a 32bit xl 2010 on windows 8.1, the other is 64bit xl 2010 on windows 7)
I tried manually calling the Runtime.Shutdown method prior to exiting, but that didn't help. Same result.
I also tried first calling the destroy method on all WebControl.WebView objects that are live at the time of shutdown. No help.
Would it be possible for you to not add your app domain shutdown event, and let me just call Shutdown myself, or modify the Shutdown api so that it unregisters your appdomain unloaded event handler when Shutdown is called?
At this point, i don't know if it is the attempt to do something in the AppDomainUnloaded event that is the problem, or if it is that callback thing of yours that is being signaled is waking up in an unloaded app domain. What is the down side of not having that? It seemed like everything was fine before that was added.
Please let me know if there is any other information you need, or anything else i can try in order to figure out what is up here.
|
|
Rank: Administration
Groups: Administration
Joined: 5/27/2007
Posts: 24,196
|
Hi,
Handling AppDomain.DomainUnload will not cause AppDomainUnloadedException. An AppDomainUnloadedException occurs when you try to access an object that was created in another AppDomain that has been unloaded. For example, the following steps will cause AppDomainUnloadedException:
1. Say you are in AppDomain1;
2. You create a second app domain AppDomain2;
3. You create an object X inside AppDomain2. Now you hold a reference to X in AppDomain1. But in fact this reference is a proxy object that points to the actual instance which lives in AppDomain2;
4. You unload AppDomain2;
5. You try to access something (for example) on X, now you will get AppDomainUnloadedException;
All our code runs inside a single AppDomain and we never create/destroy additional AppDomains. So the problem is unlikely to have anything to do with us. It could be Excel or your plugin is creating a second AppDomain but still try to access objects in that AppDomain after it is unloaded.
In any case, you will probably want to find out the stack trace first and then go from there.
Thanks!
|
|
Rank: Advanced Member
Groups: Member
Joined: 3/11/2014
Posts: 57
|
Well, the problem is absolutely related to the EO web browser, and is new sometime since version 3.0.45.0.
It is true that in the excel environment, there is more than 1 app domain present, and my suspicion is that in the affected environments, somehow, something is different. I don't know exactly what kind of work your thread callback does when it is signaled to shutdown, but i would very much like that when I call that Shutdown method myself, from my VSTO Shutdown event handler, (which runs while the app is still very much alive) that that would truly stop all EO code, unregister all event handlers, stop all the rundll processes - everything, and not return until that is the case.
I'll try to get a little more info, but when i do catch this exception in the debugger, there is no stack trace available. There really is no other information that i see at that point.
|
|
Rank: Administration
Groups: Administration
Joined: 5/27/2007
Posts: 24,196
|
Hi,
We do not believe the problem is on our side because we do not have any cross domain code and AppDomainUnloadedException only occurs during cross domain calls, so logically it does not make sense to us and we think you are chasing a shadow. It is possible that something we do somehow triggered a bug somewhere else, but even in that case the idea solution would be to find out the root of the problem.
One theory that could explain the fact that you did not run into this problem with earlier build is because the background thread that should have been terminated but was not terminated, which kept the appdomain from being unloaded. Since the appdomain in which we run wasn't unloaded at all, you would not get AppDomainUnloadedException. Now the background thread is cleanly killed off and our appdomain has been correctly unloaded. And when somewhere else still try to access our objects after this, you will get AppDomainUnloadedException.
We would be very happy to provide a built to you with the AppDomain.DomainUnload handler turned off ---- however as already explained, we do not believe this is the root of the problem so we feel that the same problem might just popup somewhere else in a different form after this. I would recommend you to check the current appdomain Id when you catch this in the debugger, and the AppDomain in which our component runs. If they are the same, then it's our code. If they are not the same, then it's not our code. You may also want to enable unmanaged code debugging and MS symbol server so that it might be able to give you some additional information.
We should be able to provide you a new build with DomainUnload event handler turned off either today or tomorrow ---- however this will be a test build, not an official build since we do not think this is the root of the problem. In the mean time, if you have any additional information that points to us, or even better if you can create a repro project, we will be very happy to look further. Please understand that we are not trying to kick the ball back to you, we are merely giving you our best guess on where the problem should be in the hope that it will help finding out the root of the problem as soon as possible.
Thanks!
|
|
Rank: Advanced Member
Groups: Member
Joined: 3/11/2014
Posts: 57
|
I hear ya. But i would like to try a build in which i can control the shutdown call, so when that test build is ready, please let me know.
I will pursue trying to build a small sample project that replicates the problem. Which is tricky because, as I say, it doesn't happen on all machines. So i don't know if i'll succeed in that, but that will be the goal.
Thanks.
|
|
Rank: Administration
Groups: Administration
Joined: 5/27/2007
Posts: 24,196
|
Hi,
We have posted a new build that would unsubscribe DomainUnload event when Runtime.Shutdown is called explicitly. In another word, the event handler still present and will only be removed if you call Runtime.Shutdown explicitly in your code.
Please let us know how it goes.
Thanks!
|
|
Rank: Administration
Groups: Administration
Joined: 5/27/2007
Posts: 24,196
|
Hi,
We have posted a new build that changed the thread pool back to a dedicated background thread. Please see your private message for the download location.
Thanks!
|
|