I am able to reproduce this issue on Latest Canary#61.0.3161.0 for 'Win7'.

Tested on Chrome Stable #59.0.3071.115, Canary #61.0.3161.0 on Windows 7 and able to reproduce the issue only if the height of the browser is reduced. However in the mentioned URL, it is always seen. Screencast is attached for reference.

Observations:
1. Able to notice the similar behavior  from M-45 #45.0.2454.85. 
2. Similar behavior  is also noticed on Windows 10, Mac 10.12.5 and Ubuntu 14.04.
3. Similar behavior  is also noticed on FireFox and screencast is attached for the same.

@m.unarist -- Could you please let us know if the mentioned behavior is the intended issue. Kindly let us know if have missed anything.

Thanks in advance.

Deleted: 746528.mp4 2.5 MB

	746528.mp4 2.5 MB View Download

Deleted: Firefox.mp4 1.7 MB

	Firefox.mp4 1.7 MB View Download

@pnangunoori

Thanks for try to reproduce. However, in your screencast, looks like you only did manual scrolling and didn't click the button. There is blank space in bottom of the page, so you can see it by scrolling down to the bottom. It's not a problem.

"Insert element" button inserts new element to the top of the div element. If you already scrolled page down until the top edge of the div element protruded from viewport, you will see contents of the div element on the same position as before clicking button, due to Scroll Anchoring.

I think Scroll Anchoring should change scrollTop of the div element and keep scrollTop of the window, but Chrome changes windows's scrollTop actually.

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

@M.unarist -- I am sorry that in the screen-cast provided clicking on the “Insert Element” button is missed. Please refer the updated screen-cast of the same. Please let us know if we have missed anything.

Thanks.

Deleted: 746528_2.webm 3.7 MB

	746528_2.webm 3.7 MB View Download

Hmm...OK, I attached updated HTML and screen-cast captured with Chrome and Firefox. I've increased height of elements and also added guide line for first scrolling. Could you check this?

Looks like this issue may not occurs on some scroll position...

Deleted: test.html 824 bytes

test.html 824 bytes View Download

Deleted: chrome.mp4 69.1 KB

	chrome.mp4 69.1 KB View Download

Deleted: firefox.mp4 64.1 KB

	firefox.mp4 64.1 KB View Download

I can reproduce scroll jumps in the main window, both in the attachment in #8 and in the link on the original report. 

Assigning to skobes@ for triage.

Steve, can you take a look at this issue?

I no longer see scroll anchoring adjustments to the main window with this repro.

The #box div scroller has no overflow, so it cannot scroll.

If "Insert element" is pressed repeatedly, it eventually has overflow.  But there are still no scroll anchoring adjustments to the #box div scroller, because its scroll offset is 0.  Scroll anchoring is only active when a scroller has a non-zero scroll offset.

The main window actually should be performing a scroll anchoring adjustment in this case, and (based on bisect) was doing so prior to the launch of root layer scrolling.

The fact that it no longer does so appears to be a bug relating to subtree layout roots, which I have filed as issue 920289.  (This bug existed prior to RLS, but RLS expanded its scope.)