It's tempting to blame this on the fact that URL bar transitions cause the ICB size to change, which doesn't happen with Chrome (bug 1515980), but I think that's a red herring.
One can easily imagine a similar scenario in a case where the ICB size is legitimately expected to change (for example, with desktop zooming because the user resizes the browser window). I think the visual scroll offset jumping by a potentially large amount in response to a small change to the ICB size is unexpected, regardless of what triggered the change to the ICB size.
I think the real issue is that we rely on the early-exit in
ScrollToImpl() to avoid the visual scroll offset being clobbered by the layout scroll offset in cases where the layout scroll offset "didn't change". I think the issue here hinges on our precise definition of "change"; arguably, being re-clamped to account for the layout scroll range having shrunk shouldn't be considered a "change" for this purpose.
I have a candidate fix for this; I don't love it because it feels like we're heaping more and more logic related to scroll origins into
ScrollToImpl(), but I don't have a better idea at this time.