To all, I hope this helps.

This is the 2nd BUG I've found in Chrome and EO.WebBrowser today, for which I say, I'm not trying to find BUGS, but me being here is more to defend EO.WebBroswer, as it is AWESOME, to properly point the blame where due, which is Chrome, which in turn is what EO.WebBrowser is modeled after. In other words, EO.WebBrowser is doing exactly what it said, which was to duplicate Chrome's functionality.

In Chrome (as of 8 AUG 2017), and the EO.WebBrowser (as of 2017), there is a weird BUG, which I can not easily reproduce from my proprietary code, to make a sample for. I have a parent HTML document, which has inside a IFRAME, where the user inside the IFRAME, clicks on a button, and the code inside the IFRAME then invokes AJAX, which upon success, draws and populates dynamic HTML elements. To clarify, the events are driven by a button click, and NOT window.onresize, or any other HTML based event. For reasons unknown, Chrome and EO.WebBrowser issues a window.onscroll event to the parent, which moves the body of the parent up like 10 pixels. The parent's body has "overflow: hidden", and does not monitoring of the client, to detect things, and otherwise issue window.onscroll to itself. Likewise, the IFRAME and its code, is not coded to monitor the parent and issue the window.onscroll.

I confirmed this was a BUG with Chrome and EO.WebBrowser, by adding to the parent, a window.onscroll event handling to issue a console message. Then, I tried the code on other browsers, including IE/Edge, which never got the window.onscroll event to launch, but always got it for Chrome and EO.WebBrowser.

The workaround for thie BUG, was to code in the parent the following:

window.onscroll = function(event) { window.scrollTo(0, 0); };

This fixed the BUG in Chrome and EO.WebBrowser.