HTMLViewer - Neither Webkit nor Native doing their job

Hi All - I’m looking to see if anyone else has ideas of how to solve my situation, which I had /hoped/ to be cured by the recent implementation of webKit3, but to no avail. I know of at least three people on here who have voiced similar issues, but I don’t know whether they have managed workarounds.

Problem: My major application, currently being sold through at least 20 education authorities in the UK and more soon in Europe is still stuck on 2016r4 because of a problem that seems to have been introduced in 2017r1 and never cured. I can’t update as neither Webkit nor Native mode in HTMLViewer is doing their job (different issues). A feedback was raised for the former and confirmed quite a while ago, but it has not been cured.

Situation: The bulk of the application is a standard Form based management system, but it has a web-page based interrogation system pre-login that unskilled users can use to interrogate the database. All results need to be generated dynamically from SQLite / Cube databases, based upon a ‘theme’ folder which contains both language and images. All resulting pages are therefore local, with links detected and acted upon by the HTMLViewer events, and links to images etc. on the local machine.

Native: Despite all versions of Edge, IE, Chrome etc. rendering properly, the HTMLViewer implementation of DIV’s (possibly more, but DIVs are the killer) using absolute positioning etc. does not work. Instead of multiple blocks across the page (e.g. inline-blocks), ‘Native’ displays them beneath each other as if inline-blocks are not being supported. Bit off as this is meant to be ‘native’ and yet the ‘native’ browsers do not have any problem with it, but I’ve not pushed this one as Native is not my preferred choice in any case and I’d rather avoid it - if for no other reason that we sell Win, Mac and Linux versions of the product and I’d much prefer to have them all running Webkit as a standard choice (Mac and Linux BTW, have never given us problems - it’s always been the Win implementation).

Webkit: Does not honour local file paths (v2017r1 onwards, 2016r4 has no issue). This is the big one. This was reported last year as a feedback, confirmed by Xojo, but never fixed. With the implementation of Webkit3 in 2018r2, I’d hoped that this would be resolved, but in fact it is now worse - a complicated workaround at the time of copying all files (dynamics, images etc.) into temporary locations from the normal configuration every time they were built then loading from the temporary directory, no longer works /at all/. Doing a lot of non-xojo research there does seem to be random adherence to allowing access to local files in Webkit (TBH, this does not sound like the original feedback case I reported, but it certainly sounds like it now). I’ve found issues reported across the board, including C++, C# and VB, with some indicating that there is a webkit flag allowing access to local files that needs to be turned on (it can be turned on as a command-line switch for example, when starting Chrome), but it sounds like a build-flag that Xojo have decided to not utilise. The feedback case was not updated, either way.

I’m now at the point of deciding that post 2017r1, HTMLViewer is a totally useless control other than doing bog-standard display of web-server based webpages. I’m faced with recoding a massive swathe of the application to provide a custom interface rather than a very simple web-page solution that clients are familiar with through everyday use of browser - we are now nearly two years behind current Xojo release, and I can’t let this go any longer.

Naturally, I’d rather not have to redesign and recode. Has anyone been able to work around this problem?

Note: Before people start to suggest switching to a local webserver, internet server etc. as a solution, please don’t. This application is utilised by clients in locked down environments (where it is impossible for them to support local webserver implementations), or in locations where reliable internet access is not a guarantee. This solution /must/ be inherent to the application, and totally local.

Load the HTML files using a TextInputStream then pass the page content to LoadPage?

I use the HTMLViewer for some pretty heavy stuff, and I’ve never seen DIVs rendering incorrectly in the WebKit renderer, nor do I have trouble loading pages from memory. I have run in to the local file issue you mention, but TextInputStream fixed that.

CSS inline-block has weird support in IE7 (source) and the “Native” engine for HTMLViewer ends up being IE7 (source).

You should reimplement your HTML to operate within the security guidelines of Chrome or you’re just going to have headaches for the rest of forever.

You should try the IE11 rendering engine by setting a registry key - see https://documentation.xojo.com/index.php/HTMLViewer for a code snippet

Yes, there is a security issue here with local files. One way around it is to set up a web server to serve the files on localhost. There are some one-line python commands which can do this for you. I’m also working on a Xojo-built HTTP server command line tool for this reason (and I may release it publicly, but it’s not ready for prime time just yet).

And just to clarify : if they can run your app, they can run a local web server contained within your app - the permissions necessary are basically the same to do either one. So I think your conclusions that this is an unworkable solution is not correct.

Many corporate environments will enforce rules like preventing listening ports.

Most typically there is a prohibition on listening on the public WAN IP, but not on localhost.

In fact, in Windows builds, Xojo’s IPCSockets are just TCP sockets bound to localhost. If the IT department has the computer that locked down, a bunch of things are going to not work.

Guys, on the local webserver issues etc. unfortunately, the biggest problem is not technological, but political. We are not talking clients here who often even have their own IT staff member (i.e. singular, let alone departments) but clients who are increasingly outsourcing their IT support and paying for 1 day every two weeks. Unfortunately, that’s the world we live in where budgets are being slashed on a daily basis.

Any application that is in anyway ‘non-typical’ (according to their local contracts and agreements) is either rejected or causes a significant increase in their support contract payments - it’s the main reason why we can’t put in local servers of any type, and we have to field multi-user database access across the web (where possible). Even if we could get agreement on installing a webserver-like environment, internal or otherwise, the idea of asking one of them to open up a port for example, fills clients with horror - it just gives these IT support companies a way in to charge lots of money for next to no work.

I even had an argument on site with one of these people who refused to copy a single 15kb text file into place to give the site a custom report - in the end, a member of the local education authority had to physical drive to the site and do it themselves.

@Anthony Cyphers: Other that the local file access (which includes image links), the Webkit is fine - it’s the Native render that has issues with DIVs and (agreed with Michael D), it’s even documented on the MS website with developers seeking help (and not getting any, as usual) - its only some parts of the CSS tags that are bad. Unfortunately, its the ones that we would need.

[quote=400537:@Michael Diehr]Most typically there is a prohibition on listening on the public WAN IP, but not on localhost.

In fact, in Windows builds, Xojo’s IPCSockets are just TCP sockets bound to localhost. If the IT department has the computer that locked down, a bunch of things are going to not work.[/quote]

Yep, exactly, and it’s one of our banes. We have even had to recode various aspects of applications to get features to work that are being prevent for exactly this reason. Long term, it has worked out easier to bite the bullet and do this that try to argue it out with these support companies.

[quote=400482:@Michael Diehr]You should try the IE11 rendering engine by setting a registry key - see https://documentation.xojo.com/index.php/HTMLViewer for a code snippet

Yes, there is a security issue here with local files. One way around it is to set up a web server to serve the files on localhost. There are some one-line python commands which can do this for you. I’m also working on a Xojo-built HTTP server command line tool for this reason (and I may release it publicly, but it’s not ready for prime time just yet).[/quote]

While Native is not the preferred option, we have actually tried this approach - in fact it is standard in another application to first check and reset the render version. Unfortnately, it did not help for this problem.

My commiseration for the lovely IT departments.

Have you tried the MBS plugin? https://www.monkeybreadsoftware.net/pluginpart-chromium.shtml . This will make your app much larger, though.

Thanks Beatrix, we have looked at a lot of MBS software over the years, but we have a policy on this one that we use as few external plugins as we can. As a nearly 3 decade veteran of VB/VS before switching to RB, the experience of plugins and addons going out of support when environments change left a bad taste in the mouth. Nothing against any producer of them, but when it happens, it’s a killer for a wide use application - even for short periods of time while they are being updated. Admittedly we use some of the Einhugur plugins, but it was a big issue internally getting them authorised.

I’ll keep the MBS solution as a last resort, just in case, It may come to the point that with us now nearing the 2 year lag in Xojo version, that we have to take the lesser of two evils (policy wise) and do something like this.

Well, Einhugur and MBS Plugins both exist over 15 years already.
They are well known in the community, used by most of the developers on the forum and should not be seen as a problem, but as a helper for solution.

Craig, can you provide an example of the issues you’re seeing with the DIVs so we can have a tinker? I’d put something together and test that but there’s no point as your implementation might be slightly different so we might as well test with your method.

As Michael mentioned, an open port that is bound to localhost (not the local IP) will never throw a firewall issue. Here’s some old code of mine that I wrote for Michael showing how to bind to localhost because you can’t do it with Xojo directly.

https://www.dropbox.com/s/lumt98gxhn0sfh9/TestSocketListenOnLoopback.xojo_binary_project?dl=1

Run the program, press the button then telnet to localhost 30000 and press ‘a’ to see the example.

There’s no way any IT department will stop that because its how IPC works and its not a security issue because outside connections will not be able to connect to that port.

(By the way, much appreciated Julian, thank you) - Julian’s code allows you to bind to localhost in older versions of Xojo, but in newer versions you can just use NetworkInterface.Loopback: https://documentation.xojo.com/index.php/NetworkInterface.Loopback

So in more recent versions of Xojo you can just do this:

    // default to loopback (localhost) interface
    dim ni as NetworkInterface = NetworkInterface.Loopback
    dim m as new ServerSocket  
    m.NetworkInterface = ni
    m.Port = 0   //   Listening on port 0 means "automatically choose any available port from 1025...65535"

And to reiterate - while it’s not impossible that an over-zealous IT department could break this, I’ve never had any reports of it happening in my commercial shipping product.

Ah yeah, 2016r2 introduced loopback :slight_smile:

Hello Craig

I had problems with how the native HTMLViewer rendered tables. It basically boiled down to IE defaulting to version 7 emulation for the native render engine. Michael mentioned earlier that a registry setting can be changed to switch the render engine emulation, but I didn’t want to resort to changing the registry. It turns out that your HTML can request which emulation mode IE runs. Here is an example of the HTML Header that I use. The important line is the 5th line (<meta http-equiv="“X-UA-Compatible”" content="“IE=9"”>. This directs IE to use version 9 emulation. I do not use DIV’s in my html so I don’t know if it will work for you, but it fixed my table rendering woes. See also stackover

Lines.Append "<!DOCTYPE HTML PUBLIC ""-//W3C//DTD HTML 4.01//EN""" Lines.Append """http://www.w3.org/TR/html4/strict.dtd"">" Lines.Append "<html lang=""en-us"">" Lines.Append "<head>" Lines.Append "<meta http-equiv=""X-UA-Compatible"" content=""IE=9"">" Lines.Append "<style type=""text/css"">" Lines.Append "body {font-size:12px;font-family:Arial, Helvetica, sans-serif;}" Lines.Append "#table1 {page-break-inside:auto; border:1px solid black;}" Lines.Append "#table1 {width:"+Str(TableWidth)+"px;border-collapse:collapse;font-size:12px;font-family:Arial, Helvetica, sans-serif;}" Lines.Append ".col1{width:9%}" Lines.Append ".col2{width:6%}" Lines.Append ".col3{width:6%}" Lines.Append ".col4{width:15%}" Lines.Append ".col5{width:16%}" Lines.Append ".col6{width:16%}" Lines.Append ".col7{width:16%}" Lines.Append ".col8{width:16%}" Lines.Append "#th {border-left:1px solid black;padding:4px;}" Lines.Append "#table1 thead {display:table-header-group;}" Lines.Append "#table1 tfoot {display:table-footer-group;}" Lines.Append "#table1 tbody, th, td {border-left:1px solid black;padding:3px;}" Lines.Append "#table1 td:first-child {border-left:none;}" Lines.Append "#table1 tr {page-break-inside:avoid; page-break-after:auto;}" Lines.Append "#table1 tr.alt {background-color:#"+str(App.lbAltRowColor).Right(6)+";}" Lines.Append "</style>" Lines.Append "<meta http-equiv=""content-type"" content=""text/html; charset=utf-8"">" Lines.Append "<title>ECN History</title>" Lines.Append "<meta name=""generator"" content=""ECN History"">" Lines.Append "</head>"

@Duane Randall : Cheers Duane, I’ll take a look at that and see it if it helps. We have been writing the registry entries to tell Windows to use the IE11 version, as documented in the Xojo manual, but to no end. Might help if it is embedded in the HTML, to I’ll give it a go.

I am putting together a small text project I can load at the request of a few of you to demonstrate what it happening, but it’s going slow. Not only am I setting up the IT environment (building about 2 dozen servers at present) for a new years’ college HE delivery, I am of course running a company at the same time.

It should have been simple, but the working HTML from the application in question is failing in both Webkit and Native in the test project at present, so I’m investigating it in spare moments - got to admit however, I am putting it together in v2018r2 rather than the v2016r4 that the main application is currently using, but I can’t see how this should in any way be affecting it.

I’ll post when I can.

A test project is welcome.
While I can work around a few things via plugin, if IE 11 or Chromium doesn’t render it right, there may not be mich we can do about it.