DesktopHTMLViewer rendering controls in wrong position

Targets Windows
1

Hi all,

Having a problem with the DesktopHTMLViewer on Windows (works fine on Mac).

See the screenshot below. The ribbon at the top of the window is done in HTML/CSS/JS. When the user tries to select an item from the drop-down list, the list is drawn in in the wrong position. This occurs after the window has been moved, in fact the position the menu is drawn in would have been correct for the old window position.

2023-08-20_05-14-18
2023-08-20_05-14-181920×1382 166 KB

I’m at a loss on how to even begin to resolve this. Any ideas?

Thanks in advance.

2

Windows uses Embedded Chromium which is a stripped down version of Chrome. I’d start there and see how your page looks in Chrome, but beyond that you’re kinda stuck.

3

Thanks Greg,

The page looks fine in every browser, including the latest Chromium which I compiled myself. This seems to be a bug in the DesktopHTMLViewer.

I’ve built a sample project, can anyone confirm? Run the project, move the window, then click one of the dropdowns. It works fine on Mac but on Windows the dropdowns draw in the old window location.

https://www.dropbox.com/scl/fi/lpuqaplon3nhj1udueljd/DropdownBug.xojo_binary_project?rlkey=yz55pntnd1fw7ocum8dit62xc&dl=0

4

You can also easily create your own example by loading any page on the internet with dropdowns (the <select> element), such as the Mozilla developer page for the select element:

Load that link in a DesktopHTMLViewer, move the window, and note the position of the dropdown.

5

After hours of trial-and-error I found a workaround.

In the Window.Move event add:

#If TargetWindows Then
HTMLViewer1.Width = HTMLViewer1.Width + 100
HTMLViewer1.Width = HTMLViewer1.Width - 100
#EndIf

The resize of the viewport somehow forces the embedded chromium to recalculate its internal graphics positions based on the new Window position. Wastes a few CPU cycles but it does the job.

2 Likes