Why would it not be affected by the zoom factor?

In case of zoom-in, pixels are bigger, so scroll to 5 pixels should scroll exactly to 6-th pixel, not 5.5. And it's work just fine. 

The problem is read scrollTo value from script. It's differs from value I set just before:

this code:
element.scrollTop = 5;
console.log(element.scrollTop)

prints 4.800000190734863 instead of 5. And magic happens only with scrollTo, other properties are OK: what I set is what I read.

reporter@ Thanks for the issue.

Tried to reproduce this issue on Windows 7 ,Mac OS 10.12.6 using the latest Canary 63.0.3236.0 and Stable 61.0.3163.100 following the below steps.

1. Launched Chrome and opened the given .html file.
2. Zoomed the page to 125% and executed steps 2 & 3 in console of Devtools.

Please find the attached screen shots of the results in Windows and Mac and confirm if anything is missed from our end.

Request you to please provide us the screen cast for better understanding and help us with the expected behavior.

Thanks..

Deleted: 772393.png 63.4 KB

	772393.png 63.4 KB View Download

Deleted: 772393_Mac.png 63.6 KB

	772393_Mac.png 63.6 KB View Download

susanjuniab@ The example html page already have zoom factor for test purposes, so you don't need to set it manually.
<div id="element" style="zoom:125%;

If you remove "zoom:125%" style, then numbers will be same on 100%, and only begins to change on zoomed pages.

So I don't think you missed something - as you can see, you set up value for scrollTop property (5) and read back absolutely different value (approx 4.48...).

In real-world application I don't know how to manually fix it: I have a scroll view, scroll it down to 65px, catch onscroll event and have no idea where the view really stands.

Btw, scrollTop set/get values absolutely identical on all browsers, except Chrome.

Thank you for providing more feedback. Adding requester "susanjuniab@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Able to reproduce this issue on Mac 10.12.6, Win-10 and Ubuntu 14.04 using chrome reported version #61.0.3163.100 and latest canary #63.0.3236.0.
This is a non-regression issue as it is observed from M50 old builds. 

Hence, marking it as untriaged to get more inputs from dev team.

Thanks...!!

This is a consequence of the fact that Blink stores all scroll offsets as Ints so we lose some precision in the conversion. This would be fixed by issue 414283, unfortunately that's not a short term fix...

This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot