In Firefox, setting location.hash = location.hash will scroll the page back to the current anchor's position. In Chrome and Safari, setting location.hash = location.hash is ignored.

The HTML Standard's description of the hash setter steps does not include a special case for checking whether the new hash is equal to the current hash. My reading of the steps is that the browser should 7. Location-object navigate to copyURL even if copyURL is the same the current URL. In that case, Firefox is following the spec'd behavior and Chrome and Safari are not.

https://html.spec.whatwg.org/#dom-location-hash

Here is Chromium's hash setter implementation where it bails early if the new hash is equal to the current hash:

https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/frame/location.cc;l=203-204;drc=984c3018ecb2ff818e900fdb7c743fc00caf7efe

Steps to reproduce:

1. Load https://en.wikipedia.org/wiki/Firefox#Features
2. Scroll the page.
3. In the devtools console, execute location.hash = location.hash

Result:

In Firefox 94, the page scrolls back to the #Features anchor position. In Chrome 96 and Safari 15, the page does not scroll.

If you replace step 3 with location.href = location.href, Firefox, Chrome, and Safari all scroll back to the #Features anchor position.

This difference in behavior causes a webcompat problem reported in this Firefox bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1733797

Steps to reproduce:

1. Load https://lithic.com/legal#terms
2. Try to scroll the page using a touchpad, keyboard, or mouse wheel.

Result:

In Chrome 96 and Safari 15, you can scroll the page and the fragment of the URL in the address bar changes as you scroll to each document section on the left of the page ("Terms of Service", "Privacy Policy", etc).

In Firefox 94, you can't scroll the page because the page has a scroll event handler that sets location.hash to the current document section's anchor. Firefox can't scroll because it keeps returning to the current anchor's position.