Hello,

regarding the Webbrowsers navigation events I have a question. In my understanding, every top level window (MainFrame) should fire a LoadComplete-Event. I mean, if I make a "LoadUrl" or click a Link, I have (at least) one BeforeNavigate Event and I should have one LoadComplete Event.
In my tests, the LoadComplete Event is not always fired.

Best regards,
Michael

Hi,
it behaves like you described. Thank you for your tip, I will try with the IsLoading Event/Property.

Thank you!

Along this line, our application seems to sometimes lose the URL when the LoadCompleted event gets triggered.

Top of code:
webView1.Url = sourcepage.ToString();
webView1.LoadCompleted += webView1_LoadCompleted;

....

void webView1_LoadCompleted(object sender, NavigationTaskEventArgs e)
{
log.lvList.Items.Add(string.Format("LoadCompleted: Error: {0}", e.Task.ErrorCode));
log.lvList.Items.Add(string.Format("LoadCompleted: IsAborted: {0}", e.Task.IsAborted));
log.lvList.Items.Add(string.Format("LoadCompleted: URL: {0}", e.Task.Url));
screenReady(e);
}

No error code (OK), but the URL is empty. This then gives an HTTP status code 0 and "The connection was aborted".

This is using the latest EO browser in a WinForm. And it does not happen all the time, but only on some machines. Unfortunately we don't have access to all the machines: this is a click-once application. Our internal testing did not show this issue, and only on a remote terminal server running Windows Server 2012 can we recreate it. But users are experiencing it (so we had to roll back to our previous web engine, which I really, really want to get off of!)

Any assistance would be appreciated.
Let me know if I should open a new thread for this particular option.

The LoadURL gives the same results. I am working on the 2nd option.

Oddly, though, while testing I've loaded Fiddler up to see the traffic. With Fiddler up, it always works. Without Fiddler, it does not work. When it does not work the NavigateTaskID is always 1 greater than the navigationtaskID from the original:

nTask = webView1.LoadUrl(sourcepage.ToString()); // original task
...
void webView1_LoadCompleted(object sender, NavigationTaskEventArgs e)
{
log.lvList.Items.Add(string.Format("LoadCompleted: taskID: {0} [{1}]", e.Task.ID, nTask.ID)); // e.Task.ID = nTask.ID + 1
...

There is something interesting going on in the network stack, but being unable to observe it makes it complicated (what I call the technician syndrome: works fine if the tech is watching, in this case, Fiddler)

doing that yields the following:

ErrorCode: ConnectionAborted
Message: The connection was aborted.

The URL matches the calling URL. Could there be some sort of race condition? This does work on a lot of computers, but there are enough of them breaking down that is causing the issue. Internally it works on my Windows 8 machine, the QA Win 7 machine, fails on a Windows Server 2012 machine and several unknown (click once) machines in the wild.

Hi,

This is more likely an issue in the network stack. What happened is, the original request failed because of a network issue (for example, your server abruptly closing the connection is one possibility). When this happens, two thing occurs:

1. LoadFailed event handler is called;
2. Internally, WebView calls LoadHtml to display an error message for this failed event. This triggers the second NavigationTask (with ID one above your task Id). This task obviously will complete successfully, which triggers your LoadComplete event (we should probably skip LoadComplete event for such internal taskes);

In order to troubleshoot such problem, you must get a network monitor to monitor the network traffic directly (you can try WireShark). Fiddler won't work for such cases because it acts like a proxy in between, so it might just somehow fix the connections. You can also try to point the WebView to a different page/server to see if you see the same problem. The problem maybe related to SSL.

Thanks!

No problem. Please keep us updated.

Turns out our servers did not handle TLSv1.2 and would drop back to 1.1. Apparently some Windows machines handle the degradation correctly, some don't (and our QA machines all worked of course!)

We're in the process of correcting that, and on our test environments (once we found a machine configuration that would fail) the server update corrected the issue.