|
|
Rank: Advanced Member
Groups: Member
Joined: 7/20/2015
Posts: 52
|
Hello All,
I think I've found a bug with EO.WebBrowser that's surfaced because I've added an additional WebControl to my application (had 3, now have 4). Please review my notes below.
Thanks,
JK
Scenario:
WPF application.
I'm running EO.WebBrowser 15.3.31.
Windows 7, .Net 4.5.
I'm using the default EO engine (not instantiating any additional engines).
I have a UserControl that contains a WebControl declared in xaml as such: <eo:WebControl Name="WebControl" />
I do not explicitly declare or assign a WebView to WebControl. I'm using its default view.
The UserControl's .cs navigates to a web page using any of the following methods:
this.WebControl.WebView.Url = myUrl;
this.WebControl.WebView.LoadUrl(myUrl);
this.WebControl.WebView.LoadUrlAndWait(myUrl);
I have 4 instances of my UserControl, all of which are instantiated and loaded at the same time.
Behavior:
Sporadically, 2 or 3 out of the 4 display the web page. 1 or 2 do not.
Observations:
I can see on my web server that all 4 web pages were requested and served by the web server successfully.
No exceptions in my log. No EO crash log.
WebView is still running. Using context menu to try going forward/back does nothing. View source shows the standard eo.blank HTML.
When using LoadUrl with a NavigationTask and using WaitOne with timeout (say 15 seconds), WaitOne returns false. The NavigationTasks's ErrorCode is "OK", IsAborted == false and IsDone() == false.
Things I Have Tried That Didn't Work:
Upgrading to 16.0.36 (this actually made the problem occur more frequently).
EnableLargeAddressSpace = true, and using eowp.exe (this solves a different problem, so thanks for that!)
Making sure that my UserControl and WebControl are Loaded before trying to set the URL.
Synchronizing my URL-setting code inside of a lock such that only one of my UserControl's instances can navigate at a time.
Reload after Url_set/LoadUrl/LoadUrlAndWait.
Try loading the same URL again on a timer.
Testing that the Url I assigned is still what I assigned immediately after Url_set/LoadUrl/LoadUrlAndWait as well as after an elapsed time - it is always equal.
Declaring the WebControl's WebView in UserControl's xaml, and in the UserControl's ctor.
Combinations of all of the above.
Thing I Tried That Worked But I Don't Feel Great About (aka, the ugly workaround):
Use LoadUrl, and WaitOne. If WaitOne returns false, instantiate a new WebView and assign it to WebControl, then use LoadUrl again. Here's the code:
private void LoadUrl(int attemptNumber)
{
var waitTime = attemptNumber * WaitTimeIncrement;
var navTask = this.WebControl.WebView.LoadUrl(this.Url);
var waitSucceeded = navTask.WaitOne(waitTime);
if (!waitSucceeded)
{
this.WebControl.WebView.Dispose();
this.WebControl.WebView = new WebView();
if (attemptNumber != MaxAttempts)
{
attemptNumber++;
this.LoadUrl(attemptNumber);
}
}
}
|
|
Rank: Advanced Member
Groups: Member
Joined: 7/20/2015
Posts: 52
|
Update: My workaround isn't reliable. Sometimes the first wait succeeds, yet the WebView still doesn't display the page.
|
|
Rank: Advanced Member
Groups: Member
Joined: 7/20/2015
Posts: 52
|
Update: Noticed that when WaitOne returns false, this.WebControl.WebView.Url == "". Even if I put code inside the else to assign Url to something, in the watch window immediately after the assignment I can still see Url == "".
|
|
Rank: Advanced Member
Groups: Member
Joined: 7/20/2015
Posts: 52
|
Update: Seems to be tied to showing 2 WebViews at the same time.
|
|
Rank: Administration
Groups: Administration
Joined: 5/27/2007
Posts: 24,229
|
Hi, Please try build 2016.0.42.0 and see if it fixes the problem. This build fixed a reentering scenario that can cause the browser engine to crash or hang when there are multiple LoadUrl request issued concurrently. If the new build still does not fix the issue, please try to isolate the problem into a test project and send the test project to us. You can find more information on test project here: http://www.essentialobjects.com/forum/test_project.aspxThanks!
|
|
Rank: Advanced Member
Groups: Member
Joined: 7/20/2015
Posts: 52
|
Just following up here. Unfortunately the upgrade doesn't fix the issue. Will try to put together a sample to demonstrate the issue.
|
|
Rank: Administration
Groups: Administration
Joined: 5/27/2007
Posts: 24,229
|
No problem. We will look into it as soon as we receive it.
Thanks!
|
|
Rank: Advanced Member
Groups: Member
Joined: 7/20/2015
Posts: 52
|
Hey guys - no sample project yet BUT a valuable update. I took all other views out of the mix except one and it still sometimes shows blank. In one instance I saw it "flicker" and show my page and then quickly go to blank. I can see it executing my javascript as well. When i view source, this is what i see:
<!--eo.blank--><html><head></head><body></body></html>
Further, I have seen this behavior even after it's shown my page once successfully if I navigate to a different page and then back. What would cause it to leave my page and go to this blank page? Is it a lifecycle/timing thing of when I'm setting the url? Is it something in my javascript? This is a really frustrating issue...
|
|
Rank: Administration
Groups: Administration
Joined: 5/27/2007
Posts: 24,229
|
Hi,
This is the initial blank page when the WebView is just created. Do you have some logic that recreates the WebView when the WebView has crashed?
Thanks!
|
|
Rank: Advanced Member
Groups: Member
Joined: 7/20/2015
Posts: 52
|
No - in fact the WebView is not crashing and it's actually requesting my page - just displaying the blank page. In my first post I was trying to recreate the WebView but that didn't prove reliable so i took it out. At this point I'm just using the default WebView that is assigned to the WebControl, and setting the Url property.
|
|
Rank: Administration
Groups: Administration
Joined: 5/27/2007
Posts: 24,229
|
That is very strange. We can't think of anything that would cause that. I guess we still need a test project. : )
|
|
Rank: Advanced Member
Groups: Member
Joined: 7/20/2015
Posts: 52
|
Some positive news from my end. I created a test project and was able to reproduce the issue with every launch (1 or 2 views showed the target page, the others did not). While setting up the test project it occurred to me that when we assign the Url parameter to the WebView, we are doing it via a DependencyProperty on our wrapper control. And when we set the dependency property, we're doing it like this:
dispatcher.BeginInvoke(DispatcherPriority.Normal, new Action<object>(this.Navigate), null);
...
private void Navigate(object argument)
{
this.EoWebBrowser.WebAddress = this.Url;
}
If I remove dispatcher.BeginInvoke, it works every time. So I was able to restructure some of my code to make sure that the call to set the web address is always on the dispatcher thread, but it would be good to know why marshalling the call onto the dispatcher from a worker thread isn't working.
|
|
Rank: Administration
Groups: Administration
Joined: 5/27/2007
Posts: 24,229
|
What is the value of this.Url? Is it blank?
|
|
Rank: Advanced Member
Groups: Member
Joined: 7/20/2015
Posts: 52
|
No, it's a valid Url string.
|
|
Rank: Administration
Groups: Administration
Joined: 5/27/2007
Posts: 24,229
|
Then please send the test project over. There is no way we could have guessed what you are doing without a test project, let alone finding out the root cause.
|
|
Rank: Advanced Member
Groups: Member
Joined: 7/20/2015
Posts: 52
|
No worries. Test project sent. Let me know if you've received it. Thanks!
|
|
Rank: Administration
Groups: Administration
Joined: 5/27/2007
Posts: 24,229
|
Yes. We have it. We will look into it and get back to you as soon as possible.
Thanks!
|
|
Rank: Administration
Groups: Administration
Joined: 5/27/2007
Posts: 24,229
|
Hi,
We have found the root of the problem and have confirmed this to be an issue on our side. This will be fixed in our next build.
Thanks!
|
|
Rank: Advanced Member
Groups: Member
Joined: 7/20/2015
Posts: 52
|
Fantastic. Thanks for the quick turnaround.
|
|
Rank: Administration
Groups: Administration
Joined: 5/27/2007
Posts: 24,229
|
Hi,
This is just to let you know that we have posted a new build (.49) that should fix this issue. You can download the new build from our download page. Please take a look and let us know how it goes.
Thanks!
|
|