Could you please fill in the bug report?  The information at stackoverflow does not make it clear to me how to reproduce your problem, what the expected behavior is, and what went wrong.

From what I understand of your description on stackoverflow, you have described 2 problems:
1/ You hover on an element in grid-template-rows and it causes the scroll to automatically start moving.  I cannot reproduce this.

2/ You are doing circles with your mouse on the li elements whilst also scrolling and it causes the scrolling to break.  I cannot reproduce this.

Aight so the expected behavior is to make a smooth scroll like it is represented on right side of the attached video.

In order to reproduce the problem you have to make a container that has hard-coded height, 3 inner-containers with display: grid; grid-template-rows: <x>vh auto <x>vh (where x === whatever number you want it to be). The middle inner-container should be overflown in order to get scroll visible and be able to scroll. Then by hovering / doing circles with mouse on middle inner-container whilst also scrolling you can reproduce the problem. 

- container on the LEFT has grid-template-row properties set as 10vh auto 8vh for heder/body/footer respectively.
- container on the RIGHT has grid-template-row set as 10vh 1fr 8vh for heder/body/footer respectively

What it seems like is the grid-template can't calculate the value of auto. However this does not seem to be grid-template problem, since in both cases (left / right container) scroll is working smoothly on Mozzila. I've checked the scrolling in Opera and it is the same behaviour as it is in Chrome, `fr` units are calculating the value correctly though auto does not (which seems odd).

Deleted: 2017-05-29 14-36-16.mp4 6.0 MB

	2017-05-29 14-36-16.mp4 6.0 MB View Download

Thank you for providing more feedback. Adding requester "joelhockey@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

I can reproduce the issue in 60.0.3095.5 too. 

The idea of 'auto' rows lead to a container's height, in this case the item's overrideContainngblockHeight, difficult to handle b the overflow logic is quite plausible. 

I'm attaching a simplified example to reproduce the issue. You just need to scroll to the bottom and then start to scroll to the top.

BTW, I cannot reproduce this if I don't use "opacity" property.

Deleted: bug-726747.html 738 bytes

bug-726747.html 738 bytes View Download

Deleted: bug-726747.ogv 107 KB

	bug-726747.ogv 107 KB View Download

I think I found another issue related to this one. Please if you think it's not related tell me and I'll open a new one.

My example is in this codepen: https://codepen.io/olivarra1/pen/RQzOqM

In there there's a react component rendering to 3 different views:
* top-left: Display: grid, cell has assigned a 1fr*1fr space
* top-right: Display: block, absolute positioning (irrelevant, it's just to get it in a nice place)
* bottom-left: Display: grid, cell has assigned a 1fr*130px space

Only the 1fr*1fr cell is having this behaviour: When scrolling with the wheel, as soon as there's an update in the DOM, the scroll resets to the lower position of that wheel scroll transition.
It's also noticable if you click-and-drag the scrollbar, because as soon as there's a DOM update, it completely stops scrolling (as if the user would've dropped the scrollbar where it was)

The other 2 examples try to demonstrate how not using display: grid, or using a determined height for the cell solves the issue (but it's still not working as expected, as it should not break scroll in any case). I also tested in MS Edge and it works properly [we only use chrome, but it's the other browser I have at hand...]

I hope this helps....