Confirmed in 64.0.3269.0 on Mac. Works in Firefox and Safari. The link appiles a hash to the URL but there's an event handler that's doing something more. The scrolling is smooth but I don't see scroll-behavior anywhere so I'm confused what's actually happening.

A bisect to start would be helpful.

Able to reproduce the issue on reported version 62.0.3202.94 and on latest canary 64.0.3270.0 using Windows 10, Ubuntu 14.04 and Mac 10.12.6, hence providing bisect info

Bisect Info:
================
Good build: 61.0.3137.0
Bad build: 61.0.3138.0

You are probably looking for a change made after 481207 (known good), but no later than 481208 (first known bad).

CHANGELOG URL:

https://chromium.googlesource.com/chromium/src/+log/148c2697ed43abbc96e517b0c65517ebcef171b7..4cef659a8009c5cb4f5708336ae37654d23653b3

Suspecting same from changelog.

@Dave Tapuska: Please confirm the issue and help in re-assigning if it is not related to your change.

Thanks!

This is breakage from scrollTopLeft interop shipping. This was an intentional change to align Chrome with Firefox, Edge and standards. See  issue 157855  for more information. The given site must be serving different code to Chrome than it is to those browsers so it should remove the browser check.

From what I can see from the code, the site isn't serving specific code for Chrome. Can someone point me to the code/script they think is targeting Chrome only?

I didn't look too deeply, but that was my assumption since the bisect pointed out that change. Since the site works correctly in Firefox, and the blamed patch only makes Chrome work like in Firefox, I assumed there's a UA check somewhere on the site.

Sure enough, if I change the UA string (using DevTools) to Firefox the site works correctly.

You are using jquery localscroll which depends on jquery scrollTo.

See https://github.com/flesler/jquery.localScroll/issues/38

Thank you so much. That has fixed it.