We were employing a method in our code to allow our blind users to upload files via various websites by clicking the file upload button for them. In order to do this, we needed to locate the button within the browser window.
We were using EO.WebBrowser.Wpf version 17.3.13.0
The following Javascript code was being used within the page to determine the control location:
Code: JavaScript
function GetElementPos(psXPath) {
try {
var els = document.evaluate(psXPath, document, null, XPathResult.ANY_TYPE, null);
if (els == null) return "NotFound";
var el = els.iterateNext();
if (el == null) return "NotFound";
el.scrollIntoView();
var rect = el.getBoundingClientRect();
var ttop = rect.top + window.scrollY - document.body.scrollTop;
var tleft = rect.left + window.scrollX - document.body.scrollLeft;
console.log("rect.top: " +
rect.top +
" window.scrollY: " +
window.scrollY +
" document.body.scrollTop: " +
document.body.scrollTop +
" ttop: " +
ttop);
return "OK," + tleft + "," + ttop + "," + rect.width + "," + rect.height;
}
catch (ex) {
console.log("** ERROR " + Date.now.toLocaleString() + " (KiraGetElementPos) " + ex.message);
return ex.message;
}
}
When we run the above code using version 17.3.13.0 we got the following console output:
rect.top: 0 window.scrollY: 467 document.body.scrollTop: 467 ttop: 0
When we upgrade to version 18.1.75.0 we get the following output:
rect.top: 0 window.scrollY: 467 document.body.scrollTop: 0 ttop: 467
And as a result, we are clicking in the wrong place.
Note that document.body.scrollTop is now returning 0 instead of 467.
Question: Is this a bug in the new version of EO.Browser? We have had to work around it, but if it were to change back in the future our software will break again.
Question: If this is a bug, is there a prior version of EO.Browser 2018 that doesn't have this problem?