Rank: Member
Groups: Member
Joined: 9/30/2015
Posts: 16
|
Can reproduce that the rendering process hangs with excessive cpu usage by using code below in wpf, and the web page cannot be navigated.
Code: C#
var handle = new WindowInteropHelper(Application.Current.MainWindow).Handle;
var web = new EO.WebBrowser.WebView();
web.Create(handle);
web.ZoomFactor = 0.46;
web.Url = "http://www.aasavis.no/";
If either changing the url or setting zoomfactor >= 0.47 it works fine... Lower zoomfactor works fine in other web pages, so it might also dissappear when the web page changes, so should be tested soon...
|
Rank: Administration
Groups: Administration
Joined: 5/27/2007
Posts: 24,229
|
Hi,
This mostly likely is related to the JavaScript code in your page. We tested with Google Chrome browser and it also has the same problem. So you might want to use Chrome browser to debug the page in order to find out the exact cause.
Thanks!
|
Rank: Member
Groups: Member
Joined: 9/30/2015
Posts: 16
|
So it's still there in Chrome 45? I suspected the problem was in the chromium code, but hoped it would be removed in the newest engine... Our customers schedule their own webpages for display, and this was a small Norwegian newspaper... The same happens for a few others as well, but as long as the zoomfactor is above ~0.47 it doesn't happen. Customers can specify zoomfactor themselves, but none have used such a low value... I noticed this error when using our preview function, where the page is further scaled down...
I also noticed that if I was only viewing one webpage (webview) where this happened, and closed it (destroy/dispose), then the rendering process is eventually killed automatically... However if I was viewing several webpages (using multiple webviews) at the same time, and this happened in one, then the faulty process is orphaned when the page is destroyed, and the processes keeps piling up for each frozen page viewed in a webview. Sometimes disposing or destroying a frozen webpage blocks the dispatcher thread indefinitely, and if not the process is orphaned...
Our system often show multiple web pages at the same time, and is running 24/7, and the content is specified by the customers. It's not a big problem if the a web-page freezes, but it would be nice if you can detect this even in the case of multiple webviews, and terminate the process when the faulty webview is destroyed.
However we are already running your webbrowser control in our production environment, and it is running fine for all customers:-) So thanks for both an excellent product and customer support!
|