>>Does not work with me.
>>
>>The example fails with a type conflict. Looking it up
>> MatchDiv.scrollIntoView({block:"center"});
>>fails.
>>https://www.w3schools.com/jsref/met_element_scrollintoview.asp says parameter is just bool., so {block:"center"} is the culprit.
>>
>>It works with the boolean, but this is not the goal
>>
>>scrollIntoView can just top or bottom according to this page.
>
>Here's where I got the parameters and this parameter works perfectly for me when I view the modified HTML file:
>
>https://developer.mozilla.org/en-US/docs/Web/API/Element/scrollIntoView
>
>It occurs to me that we're using the WebBrowser control and it may not support this parameter, since it's old. The page I linked there links to this one:
>
>https://developer.mozilla.org/en-US/docs/Web/API/Element/scrollIntoViewIfNeeded
>
>I wonder if that would work in the WebBrowser control. The compatibility charts don't include IE and the notes say this one is non-standard, but if it works in the control, who cares?

Controlling a Browser is a fast moving target. IIRC the old Trident engine basis (which WebBrowser called via 2 activeX interface typelibs) is not even installed with newer Windows, as MS created another compatibility layer working with Chromium based Edge for legacy apps. Then you have to link instructions how to enable this on new windows ;-)

As Trident engine gets about as many updates as vfp, generating different output depending on a setting which browser to call might be the best, but ugly choice. Big side benefit: if there are crazies working on throw-away VMs for projects and like to keep them small, they might develop and run under XP.

I do, with internet connection disabled this gets me VM size between 10 - 20 GB depending on other tools.

If you state in advance, that ONLY the branches with correct settings are tested, maintenance might be not too bad, as "old / other" settings will not be tested on new versions, but a nightmare if changing the basic generation engine and some difficulty filtering out incorrect settings as error source.

Would probably be best served by having test VM for every version supported, which will grow unwieldy if too many versions are supported..

That headache after maintenance stints with new machines were main reason to phase out my few download automation / browser scraping projects I started with IE3 and was really happy with up and including IE6.

I would create defined versions on XP/IE6 (get old version from source control?), W7 and latest browser supported on FF / Chrome / (Edge) and then W[10, 11] FF / Chrome / Edge with the hope that in newer versions same or near identical code can be used.

But code once, run anywhere will not work in that arena, minimize the pain by selecting few versions. IMO the best policy here is to be open about the reason not everythng is supported and indicate what combinations are tested to be working.

my 0,000002€ (as I ran away from it)
thomas