In my Windows desktop project none of the HTMLviewer controls is working as expected and as it was doing very well in previous releases.
Where I show a customers’website in the home-panel of my application, it now starts heavy likkering and showing up strange behavior when the mousepointer enters the control, like switching between a small and a large view. Unusable. Going back to 2018R2 and problem is solved.
Next, I have a HTMLviewer showing me the HTMLpage generated by the application itself. Again, was it working perfectly fine. Now it shows me the plain HTML and two scrollbars rather than the one expected. Unusable too.
I definitely want to have this solved since I want the benefits of moving to 2018R3. of course.
For the sake of science, which rendering engine is selected?
@Tim Parnell : webkit
What kind of app? 64-bit ? HiDPI or non-hidpi?
FWIW There were no changes to htmlviewer or the underlying webkit or native renderers for R3.
Windows 10, project has "Supports Hi-DPI switched OFF.
When I switch it on, the HTML viewer seems to render the websites correctly again.
But this doesn’t solve my problem since due to reasons I have switched it off.
The other HTMLviewer showing up pure HTML code, I don’t know, have to dive into.
But fact is that for me both issues are new for this release now.
Do you see CEFPROCESS.EXE in task manager after doing a Run of your app? That should shut down when the debug run finishes but if it didnt that might be a problem in subsequent runs. Maybe a shutdown and restart of the machine is needed.
Are you loading the HTML via FolderItem? Make sure the file ends with .htm or .html in that case.
What’s the resolution of your screen? Is it Hidef?
Because seems related to some kind of bug switched by “Supports Hi-DPI” OFF + something else.
Yes I load the content via folderitem and the temporary file has the extension *.htm
Only Full HD 1920 x 1080 with Win10 option “Disable display scaling high DPI settings”
Open a feedback case, include a sample with instructions, pictures, and how to reproduce.
I will create a simple test program with 2018R3 , showing this issue and put it in a FB.
Here I have a small sample project showing my issue with the HTMLviewer in 2018R1, 2018R2 and 2018R3. (Windows 10)
2017R3 was working perfectly fine.
Mind the Windows declare in the App.open event. When I disable this declare I don’t see the problem with the HTMLviewer. I have this SetProcessDPIAware to make sure my screen layout will be shown the same on every screen, like we had in windows 7.
Perhaps there is an alternative I am not aware of.
Joost, please file a Feedback case for this issue.
@Robin Lauryssen-Mitchell , did you see the issue in the demo project ?
Not yet.
This is my ‘play in the Forum hour’ 
AND I cannot respond to potential Xojo bug issues in the Forum.
That is what Feedback is for.
Off-topic question/comment, I downloaded your sample, commented the window1.show in app.open event and running on mac no window is shown. I wanted to know why. Did some tests, even created a new project and copied everything over, but with this new project Window1 is always shown.
I reviewed all settings I can think, window settings, build settings, 32bit/64bit and I can’t find why you sample needs Window1.Show, any idea what I’m missing?
[quote=411449:@Joost Rongen]Mind the Windows declare in the App.open event. When I disable this declare I don’t see the problem with the HTMLviewer. I have this SetProcessDPIAware to make sure my screen layout will be shown the same on every screen, like we had in windows 7.
Perhaps there is an alternative I am not aware of.[/quote]
That would be a problem if you’re using SetProcessDPIAware to change the DPI awareness context. This is essentially the same thing as enabling Support HiDPI in the build settings, why not just do that? The problem here is that there are two versions of the cefsubprocess, one that works with HiDPI and one that does not. When you build your app you are telling us that you will not be supporting HiDPI so we copy the non-HiDPI version of cefsubprocess. Any changes in code to support HiDPI means bad things in this case.