|
|
Rank: Advanced Member
Groups: Member
Joined: 3/10/2020
Posts: 59
|
Hi,
We are using EO.webbrowser(21.3.18.0) in our WPF application.Our end users facing issue in WPF screen embedded with EO browser.
Web page is not loading in eo browser.its shows blank window.
Seems browser is not attached in wpf window as we are not seeing the EO browser process in task manager.
We have enabled eowp.exe
There is no exception reported in our application exception log.
Please check if any exception has been reported in EO server logs and let us know what could be the reason for this behavior.
Application Name:NetX360v2.exe
Date and time:5/25 1:00 PM EST to 1:25 PM EST.
code:
EO.Base.Runtime.EnableEOWP = true; EO.Base.Runtime.InitWorkerProcessExecutable(System.IO.Path.GetDirectoryName(System.Reflection.Assembly.GetExecutingAssembly().Location) + "\\eowp.exe");
EO.Base.Runtime.Exception += Runtime_Exception;
|
|
Rank: Administration
Groups: Administration
Joined: 5/27/2007
Posts: 24,217
|
Hi, Due to the extreme large size of the Chromium project, we only maintain debug environments for recent builds. So we are not able to investigate crash reports from older builds such as 21.3.18. If you wish to investigate the issue further, please try to update to the latest build first. After that you can try to add code to caputre WebView.Closed event and log e.Reason. This will tell you why the WebView has closed. If the WebView is closed indeed due to a crash inside the browser engine, then we will search our database for crash logs and see what we can find. As always, it's always the best if you can reproduce the problem. So if you have a way to reproduce the problem with the latest build, please do not hesitate to send us a test app: https://www.essentialobjects.com/forum/test_project.aspxThanks!
|
|
Rank: Advanced Member
Groups: Member
Joined: 3/10/2020
Posts: 59
|
Hi,
We are unable to recreate the issue on demand, so we cannot share the sample repro. The only way we can reproduce the issue is by terminating eowp.exe from windows task manager.
from EO dev tools, we infer the application navigates to "about:blank" after some of the urls are successfully served.
Could you please let us know if you ever encountered any such issue in the past ("about:blank" navigation) and if yes, please let us know if you have any workaround for the same.
On the webengine crash logs, is there a way we could capture the crash logs from our side (as it is not captured)?
Is there any way to restart eowp.exe if its stopped/crashed when application is running?
Thanks.
|
|
Rank: Administration
Groups: Administration
Joined: 5/27/2007
Posts: 24,217
|
Hi,
The only time we automatically navigate to "about:blank" is when the WebView is created. After that if the page goes blank, most likely is because the WebView has been closed. This can happen either because the browser engine has crashed (the same effect if you kill eowp.exe directly), or because somewhere in your code you closed the WebView explicitly. You can handle the WebView's Closed event to find out exactly which scenario it is.
If you confirmed it is indeed because the browser engine has crashed, then please either find a way to reproduce it, or update to the latest build and we will see if we can catch any crash log.
After you handle the WebView's Closed event, you can write code to automatically recreate the WebView. Typically this part does not have anything to do with us directly --- you just "redo" whatever you did in your code to create the WebView at the first place. For example, if your application has a tabbed UI interface and the WebView in one of the "tab" crashed, you can simply throw that tab alway and create a new tab that loads the same page. This would automatically recreate the underlying eowp.exe processes.
Hope this helps.
Thanks
|
|
Rank: Advanced Member
Groups: Member
Joined: 3/10/2020
Posts: 59
|
Webview_closed event is never hitting when we recreate the issue by killing eowp.exe from task manager.
we are not explicitly calling webview close from our code.Something else is closing webview
Our application is having multiple tab functionality.when webview is blank in one tab and if we create webview in new tab,issue persist in new tab as well.EO is not creating eowp.exe for webview in new tab.
Seems your below comment is not working as expected
(you can simply throw that tab always and create a new tab that loads the same page. This would automatically recreate the underlying eowp.exe processes.)
We can see eo.engine status is running when we debug from code. seems issue is not in engine as well.
we are able to recreate this in EO tabbed browser application.Tabbed browser is getting blank when we killed the eowp.exe from task manager after that its not working when we create the new tab in tabbed browser application.
Please try this use case in your environment and let us know the root cause for this issue.
|
|
Rank: Administration
Groups: Administration
Joined: 5/27/2007
Posts: 24,217
|
Hi,
We tested the latest build with TabbedBrowser sample application and it does work correctly. Specifically:
1. WebView.Closed event is fired (you can set breakpoint in WebView_Closed in MainWindow.xaml.cs to verify this);
2. Depends on exactly which eowp.exe you kill, you will get one of the following result:
2.a. If you kill the browser engine process, then ALL WebView will be closed. In this case the TabbedBrowser sample application will close since all WebView has been closed;
2.b. If you kill a render process, then ONLY the WebView associated to that render process is closed. In this case one tab will close but you can continue to open other tabs;
2.c. If you kill other processes, they will be automatically recreated and nothing in your app should be impacted;
Make sure you update to the latest build first. Then you can try the above steps and let us know what you get.
Thanks!
|
|
Rank: Advanced Member
Groups: Member
Joined: 3/10/2020
Posts: 59
|
Hi,
Does EO browser uses console window host process?
We are unable to recreate exact scenario in which user is facing this issue.
Some how we are able to recreate partially by killing the eowp.exe and console window host.
is there any EO debugging tools is available that can be used in user machine to capture any eo process log or any other details which can be useful for debugging this issue?
User haven't faced any issues with 20.3.34.0 build.This issue is started occurring after upgrading to 21.3.18.0
|
|
Rank: Administration
Groups: Administration
Joined: 5/27/2007
Posts: 24,217
|
Hi,
Please follow our directions first.
We asked you multiple things and very specific questions in our previous posts. You said TabbedBrowser doesn't work. We provided you detailed instructions and asked you to try it on your end. You keeps ignoring what we tell you to do and keep going down whatever path you have in own mind.
You need to follow our instructions in order for us to assist you further.
Thanks!
|
|
Rank: Advanced Member
Groups: Member
Joined: 3/10/2020
Posts: 59
|
Hi,
Let me make it clear the steps you give are not helping us. We have a versioned thick client product which uses EO 21.3.18 and faces issue for end client. We need ways to troubleshoot this. We cannot take your latest and see if it resolves, it means a new release and rollout process which will get our clients frustrated. We can share what we have and how we have integrated EO. We need ways to troubleshoot the same. Hence our ask. If needed please setup a call to get on same page.
We need support for the version we use. Do you list them as unsupported and communicate to clients if so.
Thanks.
|
|
Rank: Administration
Groups: Administration
Joined: 5/27/2007
Posts: 24,217
|
Hi,
Updating to the latest build is the first step of troubleshooting these kind of issues. The reason is for unknown issues like this, very often we would need to make changes to our code (either for testing purpose or for fixing a new issue) and then upload a test build with the changes to the end user's computer for testing purpose. All such changes will be made based on the latest build. This is the most effective way to get to the bottom of the issue. Otherwise we can go back and forth a hundred times on "maybe it's this, can you try that" kind of troubleshooting. This would be shooting in the dark and in the end not only it's a waste of time for both of us, but also it would make the end customer even more frustrating.
Ideally we would need the following:
1. Setup a test environment with your customer;
2. Isolate the problem into a small test project that can reproduce the problem on the customer's computer;
3. Provide remote desktop access to us to the test computer;
This way we can connect in, add logs, run test builds over and over again until we can get to the bottom of the issue. However if it is hard for you to do that, the first step would be to update to the latest build. That would be the first thing we do if we were to troubleshoot this issue directly.
Thanks!
|
|