Hi,

If you see, "<EO blank>", then the WebView has not crashed. If you believe it should not display that, please try to isolate the problem into a test project and then send the test project to us.

If you wish to display custom message when the WebView has crashed, you can handle WebView.Closed event and then check the event argument's Reason property to see if it is "Normal". If it is not "Normal", then it's a crash and then you can display some custom message to the end user.

Thanks!

Hi,

There are two different scenarios. <!-- EO blank --> and WebView crashes. They both look exactly the same but they are different. We can not replace <!-- EO blank --> with a custom page since that page serves a special purpose. If that page does not go away, then something in the engine is wrong and just replacing that page will not fix the problem for you. So you will need to find out exactly which case it is first.

Thanks!

Same issue here using 16.1.54, WPF. My app has several WebViews, all are loaded on the Main thread using LoadUrl method. Sporadically, 1 or 2 of them display EO.Blank. I have put logging in place to confirm that after the NavigationTask is done, the Url property of WebView is what I expect it to be. Something happens to the WebView internally because in a subsequent operation, I can see that Url is back to being an empty string. I am calling LoadUrl after WebControl has been Loaded. This is very difficult to reproduce and therefore debug.

It's difficult to produce a sample project to exhibit this. Is there any code internally that would set Url back to an empty string?

You described the problem we face perfectly : /

Btw, we are loading/setting url 2-3 webviews at the same time

Hi EO Support!

This issue didn't go away (we are upgraded to 16.2.1 at this point), but I recently found a workaround that may provide a clue to you.

First, the facts:
1.) After calling WebView.LoadUrl NavigationTask is completely successful
2.) WebView and EO Runtime are still fully functional

Regardless, we still sometimes see the EO.Blank page instead of our desired page. Very frustrating because it's not easily reproducible.

Now, I have put some code in place that ensures a few things before I ever call WebView.LoadUrl. This seems to work (for now). Without these checks, we sporadically get EO.Blank:
1.) The control containing WebControl IsLoaded
2.) The WebControl IsLoaded
3.) The WebView StatusMessage is not null
4.) The WebView IsCreated

It would be awesome if there was a "IsReadyToLoadUrl" property and "IsReadyToLoadUrlChanged" event on WebView.

Additionally, I have proven that sometimes our desired page loads and then goes backward to EO.Blank after the user starts using it. We've proven that backspace key can cause this but it also happens inexplicably sometimes. So, I've added some javascript to JsInitCode that checks whether the page is blank (url starts with data:text) every 2 seconds and fires extInvoke, which calls LoadUrl again on the C# side. It's a hack but it should reduce the support calls hopefully:

var lastValidUrl;
window.onload = function () {
document.onkeydown = function(event) {
backspaceIsPressed = event.which == 8;
};
document.onkeyup = function(event) {
backspaceIsPressed = false;
};
window.onbeforeunload = function(e) {
if(backspaceIsPressed) {
var dialogText = 'Are you sure you want to leave this page?';
e.returnValue = dialogText;
return dialogText;
}
};

setInterval(function() {
if(window.location.href.startsWith('data:text') && lastValidUrl) {
eoWebBrowser.extInvoke('BlankScreenDetected', arguments);
} else {
lastValidUrl = window.location.href;
}
}, 2000);
};

Great - if you can make it so that the EO.Blank page is never displayed to a user once a real page has been loaded, I think that would likely take care of the problem overall.

Note also that sometimes it goes back to the blank page even when no user interaction has occurred and it truly seems somehow related to those properties I'm checking. Since I've put those checks in, we've had zero"no-user-interaction" blanks. Thanks!

Hi Eurice,

Thanks for the info! In our case, WebView never closes and the engine never crashes. Still looks like some good defensive code you've got there. I may borrow it!

Regards,

JK

Yes, Windows 7.