Using the per-revision bisect providing the bisect results,
Good build: 55.0.2853.0 (Revision: 416812).
Bad build: 55.0.2854.0 (Revision: 417283).

You are probably looking for a change made after 416854 (known good), but no later than 416855 (first known bad).
CHANGELOG URL:
  https://chromium.googlesource.com/chromium/src/+log/58744ea650361b518c411667574be67749d65c48..2a56f872fc3e82ccd819db4378ae2e1ac206c116

Adding RB Label as this is a recent Regression. Please remove if not required.

@toyoshim -- Could you please look into the issue, pardon me if it has nothing to do with your changes and if possible please assign it to concern owner.
Thank You.

A friendly reminder that M55 Stable is launch is coming soon! Your bug is labelled as Stable ReleaseBlock, pls make sure to land the fix and get it merged into the release branch ASAP so it gets enough baking time in Beta (before Stable promotion). Thank you!

Also due to Thanksgiving holidays in US, please make sure fix is ready and merged to M55 latest by 5:00 PM PT Friday, 11/18/16 (sooner the better).

I can see the same behavior on 54.0.2840.100 (Official Build) (64-bit).

I think this is NOT a regression.

55.0.2853.0 has another issue that can not restore scroll position correctly, and it just hides an existing bug that is reported here.

My CL fixed the bug, and the existing bug starts happening again.

This bug seems to happen because when the new navigation from the link happens, Chrome does not store the initial scroll position correctly until user takes another scroll, and the next reload restores the old information.

I'd remove ReleaseBlock-Stable since this is the same behavior with the current Stable.

cc skobes@ who may be familiar with scroll.

I'd investigate this bug again later.
I thought this happened at 54.0.2840.100 thus this should not be related to my change, but I noticed my CL was merged to 54 branch, and 54.0.2840.100 should pick it up.

My expectation is that scroll position is restored when user clicks an anchor tag to the current page, as we changed for same page navigations.

But, it does not restore the position at the navigation time, this is unexpected behavior, but restore it at the next reload time if a user does not update the scroll position.