HTML Viewer blows up app window

Windows 10 Desktop App:

I have an HTML viewer on a PagePanel in a window. I pass in some HTML text from a data source The HTML displays fine. If I set the page panel to the HTML viewer panel and leave it there for a minute, the window freezes up and I have to kill it. If I quickly view the HTML and then go to another page, it’s fine. But sitting still on the HTML for 30-40-50 seconds it freezes up and you’re done.

Here is the code:

Dim f As FolderItem = GetTemporaryFolderItem
HTMLScrapCode.LoadPage(Field_ScrapCode.Text, f)

Is this a bug?

This may have been a false alarm. Windows crashed on me and after the reboot it seems to be stable. If there are any further issues I’ll post again.

Spoke too soon. It happened again. This time it took a good 15 minutes or so.

Do you see the same thing if your HTMLViewer isn’t embedded in a PagePanel? There are a number of issues with control layering, and I know PagePanel+HTMLViewer has some issues.

Hi Anthony. Good thought. First I moved the HTMLViewer out of the panel, it still froze. Then I removed the PagePanel altogether - alas it still froze. Seems like the HTMLViewer is not getting along with Windows.

Is the HTMLViewer’s Renderer property set to Native or Webkit? I have custom components based on the Webkit renderer that are in wide use that do not exhibit this issue. If you are using the Webkit renderer, then it must be something system-specific.

Anthony, that’s great! It was set to native. I switched it to WebKit and it seems solid now. I saw that setting when I first added that object and wasn’t sure which to use. Subsequently I forgot about that setting. Thanks so much. I’ll keep it running for a while just to make sure it’s working. As I said, in a few instances it took up to 15 minutes or so before it froze. But I suspect we’re good.

Happy to help.

The Native renderer basically uses whatever old version of Internet Explorer is available via COM on the system, and is a mess. 99% of the time, you’ll want to use WebKit, though it does add additional weight to your app distribution and has some other caveats (like the occasional hanging cefsubproc.exe process).

The Native renderer will use the latest IE11 engine (which is generally quite good, as long as Windows is up-to-date), but you have to tell it to do so:
Also, when using the native renderer, you automatically get updates when the OS updates.

The WebKit renderer has the advantage of being more similar to Safari, but greatly increases the app app size; and also you don’t get WebKit updates (on Windows) until Xojo updates, you re-build, and re-release your software.

So there are pros & cons.

Still vastly lacking in standards-compliance, missing much of the modern browser feature-set specifications, and terrible in Javascript support, but yes. If you want do anything modern with Javascript in an HTMLViewer, you’re best served by sticking to the WebKit renderer. If you want to just display static HTML, you’re more or less OK with the Native renderer and IE11 engine.

YMMV. For me, it’s not that bad - I’ve written a high performance WebGL animation engine which works both in Safari and IE11 quite nicely. The IE11 quirks are super annoying, it’s true, but once you deal with some missing features via polyfills etc. the tech is pretty comparable, especially if you are using IE11 patch level 11.0.110 or higher. I ended up with less special-case code in my Javascript to deal with mac/windows differences than special-case code in my Xojo app to deal with mac/windows differences.

Also, if you switch to webkit on windows you’ll need to keep this in mind

[quote=454326:@Michael Diehr]The Native renderer will use the latest IE11 engine (which is generally quite good, as long as Windows is up-to-date), but you have to tell it to do so:
There’s a little more to it than that, even if you have IE11 latest version installed. In your HTML file that you load into the HTMLviewer, you need this:

<meta http-equiv="X-UA-Compatible" content="IE=11">

inside your section. Otherwise it may decide to render in an older mode, even if the latest is available. It took me quite a while to discover this, but once added, my javascript errors under Win10 went away, which was quite a relief given that it’s 12k lines of someone else’s incomprehensible javascript that I’m using.