The following steps convince me that history restore should cause a scroll anchor to be set:
1. Go to http://techcrunch.com/2016/04/08/spacex-just-landed-a-rocket-on-a-drone-ship-for-the-first-time/
2. Scroll down
3. Reload the page and don't interact with it...just watch it load.

History restore scrolls you down to (roughly) where you were before. But then the ads and images loading above the fold cause things to move around. It would be a much better experience if the history restored scroll position also set a scroll anchor.

This also made me think that we should consider making history scroll restoration try to be more like scroll anchoring, but that's a hard problem, so it's probably a different bug and it's more of a V2 of this feature than a V1. Filed  issue 602047  to track that.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/5114bd75de8b0e7813df98a6a2c9b43943cd4229

commit 5114bd75de8b0e7813df98a6a2c9b43943cd4229
Author: ymalik <ymalik@chromium.org>
Date: Thu Apr 28 20:36:16 2016

Test fragment scrolling and history restoration interaction w/ scroll anchoring.

This CL allows RuntimeEnabledFeatures with the option 'set_from_internals' to be set
from Internals. Previously, we could only read whether a feature was enabled.

The tests in this CL verify that we do scroll anchoring when a page has a fragment
and when doing history restoration.

Note that there are no behavioral changes in this CL.

BUG= 594880 , 594879 , 537764 

Review-Url: https://codereview.chromium.org/1895293002
Cr-Commit-Position: refs/heads/master@{#390463}

[add] https://crrev.com/5114bd75de8b0e7813df98a6a2c9b43943cd4229/third_party/WebKit/LayoutTests/fast/layout/scroll-anchoring/fragment-scrolling-anchors.html
[add] https://crrev.com/5114bd75de8b0e7813df98a6a2c9b43943cd4229/third_party/WebKit/LayoutTests/fast/layout/scroll-anchoring/history-restore-anchors.html
[modify] https://crrev.com/5114bd75de8b0e7813df98a6a2c9b43943cd4229/third_party/WebKit/Source/build/scripts/make_runtime_features.py
[modify] https://crrev.com/5114bd75de8b0e7813df98a6a2c9b43943cd4229/third_party/WebKit/Source/build/scripts/templates/InternalRuntimeFlags.h.tmpl
[modify] https://crrev.com/5114bd75de8b0e7813df98a6a2c9b43943cd4229/third_party/WebKit/Source/build/scripts/templates/InternalRuntimeFlags.idl.tmpl
[modify] https://crrev.com/5114bd75de8b0e7813df98a6a2c9b43943cd4229/third_party/WebKit/Source/platform/RuntimeEnabledFeatures.in

Realized that the current behavior may not be desirable, so re-opening. 

 Issue 613872  has been merged into this issue.

If I understand comment #3 correctly, the suggestion is to allow an initial history-restoration scroll, but allow ScrollAnchor to do its thing on subsequent layouts (so that we perform scroll anchoring at the expense of history restoration accuracy, but hopefully still end up somewhere in the ballpark).

This seems easier than  issue 602047 , and might just be a matter of tweaking FrameLoader::restoreScrollPositionAndViewState() to only restore once.

So in the current state of things, we are actually not scroll anchoring at all on reloads and refreshes. The code in FrameLoader::restoreScrollPositonAndStateView will do a ProgrammaticScroll and end up clearing the anchor (https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/loader/FrameLoader.cpp?rcl=0&l=1215). 

I am in favor keeping the behavior this way until  issue 602047 . This is because I think its not sufficient to end up "somewhere in the ballpark", especially when you're reading text. For example consider this page: https://output.jsbin.com/galoyu/quiet. If you scroll down, start reading, and hit refresh, you would end up somewhere completely different if scroll anchoring was enabled.

Lgtm. I agree we can fix this in a follow-up iteration of scroll anchoring
that handles reload and navigation properly.

I'd like to clarify "... will do a ProgrammaticScroll and end up clearing the anchor" in comment 10 a bit more.

We don't do scroll anchoring because the second call to FrameLoader::restoreScrollPositionAndViewState() overrides the anchor adjustment (as Steve said in comment 9), and not because the anchor is cleared the first time it's called. 

FrameLoader::restoreScrollPositionAndViewState is called again when a resource is loaded.

Marking this as Won't Fix in favor of doing it correctly in v2 ( issue 602047 ).