Xojo 2017.1 - Webkit Broken on Windows?

Hi All - just checking whether anyone else is getting this before I report a bug.

We are in the process of releasing a sizeable system at present with about a dozen copies going out to beta testers. With 2017.1 just popping up, it was obvious to recompile and ship out the latest release so that we don’t have to go through the same rigmarole all over again. Then we hit a show stopper.

While managerial access to the application displays pretty conventional dialogs, the front-end is HTML based using the HTMLViewer, themes stored on disk, dynamically generated content and the use of CancelLoad etc. to both load new pages, dynamically modify existing displays and so on.

Everything works fine in Mac 2016.4.1 and 2017.1 and Win 2016.4.1, in Native and WebKit, as well as being fine Native in Win 2017.1 - so we know that it is not errors in the existing code. We can’t use native as there are features / opportunities that we want from Webkit, as well as making sure that we have a standard roll-out to all the clients. The problems described below are on a pretty new Win10 machine, fully updated to latest OS release.

Bug 1: Web pages are unable to find background images. Standard CSS code indicating a background image. Works find in all other environments, but in Win 2017.1 WebKit, remains white screen. Same with background images of pseudo buttons etc.

Bug 2: Cursor changes to a hyperlink finger on mouseover of links, but the link doesn’t fire when clicked. Placed a breakpoint on the first line of code in CancelLoad - nothing - CancelLoad is not being fired. Again, works fine in all other environments described above.

Bug 3: As there are differences in what Win browsers produce as a URL in CancelLoad (i.e. a prefix with ‘file:///’ in some situations) we guessed this and modified the links to be standard ‘http://’ prefixes as a test. Again, works fine in all other environments describe above, but then fires three times in Win 2017.1 on a single click.

Anyone else seeing this? Last thing I want to do is switch to 2017.1 only to find half of the methods that we are relying on in 2016.4.1 no longer work because of WebKit on Windows, rather than being a straight-up fixable bug in Xojo.

Xojo moved from CEF1 to CEF3 for 2017r1.

I did update my plugins to use newer APIs.
Any code you wrote for CEF1 needs to be revisited.

Yeah, took that into account. From everything that we can see there is no CEF version dependant code in use - especially as it seems to be working under CEF3 on the mac. Its the same project, same CSS/HTML etc. Just failing on Windows.

A feedback case with an example project would be extremely helpful.

Yep. Next step - already in progress. Just making sure of what we were seeing :slight_smile:

hi I am testing the 2017.r1 version with the webkit and for windows I think this update is great.
I have been waiting for this along time since end 2015.

The normal renderer used the Internet explorer renderer which didn;t work with most Ajax, CSS, HTML5 and javascript intense websites.

Now the new Chrome webkit works great and I was waiting for this for a very long time!
(ps the same as the line number in the IDE, why wasn’t this it in the IDE in the first place?)

-Web pages are unable to find background images. Standard CSS code indicating a background image. Works find in all other environments, but in Win 2017.1 WebKit, remains white screen.

This could be basiscally any webpage? Do you mean that your generated html pages do not work or any webpage?
Because I can load any site perfectly using the webbrowser (HTMLviewer)

Hope you can find a solution when providing the example case

I ended up being out of the country for two weeks so never did upload the report. But on coming back, I can see that a few people have been posting similar issues with events not firing, so I’m going to spend the next few days hunting through to check what now seems to be acknowledged and what is not before loading one up.

@Pieter van den Bosch - no, my requirement is connected with detecting hyperlink selection after dynamic creation of a web-page, so nothing is ever actually downloaded from (e.g.) an internet source. Pre-2017r1, everything is fine but then the normal events raised when clicking a link are no longer firing / firing two many times.

While preparing the report to load (unfinished) I came across a few not-really-perfect work arounds which I see are partially mentioned in other posts, but I suspect the number and nature of the changed will mean that until we do a full re-work and test we’ll need to stick with the last Xojo release.

I need to refresh my memory, but I think that we did get around the white-screen problem with a very specific re-working of the css path being used, but its troubling that it works for native, but needs reworking for webkit, and then only on Windows.

If I find anything different from what I find in other posts, I’ll still upload the report.

In between released a new product, finally got around to doing some work with this. Found reasonably acceptable workarounds for many things, but not the image loading issues.

Seems to stem from the Windows v2017.1 > version of HTMLViewer not respecting the relativeTo parameter. Worked find on Windows pre v2017 and still fine on Mac. Found a mention in another post about this, but the workaround used there and the one we are currently using is not possible in some of our environments due to restricted file permissions etc. (controlled education environments). No mention of a case raised, and can’t find one matching description from others, so did so today.

Feedback case #47945.