I am working on upgrading our use of the EO WebBrowser from 2015.4.5.0 to the current version, which is 2016.2.93.0 at the time of this post. The API seems fine, but am running into a run-time error that I would like your advice how to deal with.

For background: We have a growing number of our own web applications that we integrate in our large fat client WinForms application using your WebBrowser. To mitigate risk of 3rd party API's, and such, we built our own WebBrowser UserControl that hosts your WebBrowser and encapsulates all your API behind it. We expose the API's that we need when we need them through our control. The idea is that if you guys go away someday or you decide to drastically modify your APIs or behavior we can change it in one place and all usages in our software won't even notice or need to change. Anyway, one thing we do with this encapsulation is put the events that correlate to your WebView's events directly on our UserControl. So your WebView.BeforeNavigate event is exposed thru our controls BeforeNavigation event. Hopefully you get the gist of what I am explaining.

So the problem that I am currently running into is that you started firing some of the WebView events thru background threads and not the UI thread and now we are getting cross-thread operation exceptions. I don't necessarily think there is a problem with you guys making this change, but I need to figure out how to deal with it safely and make sure I don't introduce whatever problem that you fixed. So typically when syncing to a UserControl's event (like say TextChanged) you can expect the events to be fired on the UI thread. I want this same experience from my control for my developers. So I basically need to marshal the WebView's event from the background thread to the UI thread when refiring it as my controls event. I can easily do this with the dispatcher using either BeginInvoke or Invoke, but I am more looking for advice from you. Is there a specific reason you switched events like BeforeNavigate and BeforeRequestLoad to the background thread? I worry that if I marshal it asynchronously it will change the sequence (order) of how the events are fired. If I marshal it synchronously I worry about possible reentry thread blocking issues. Anyway, I am curious if I do this will I be recreating a problem that you fixed by putting it on a background thread? Any advise around this?

Thanks,
-Jason