Note: new reload behavior will be launched soon. Once it is enabled by default, reload and omnibox+enter will take the same behavior, "don't reset user content". So, the former case isn't so important, but the latter case may need a fix.

These observations are based on what platform?  On Android 53.0.2785.80, I can't repro the described behavior.  None of the four scenarios reset the scroll or scale.  Is this perhaps a desktop-specific bug?

What I'm seeing in Stable (52.0.2743.98) on Android:

Omnibox+Enter always resets (scroll => (0, 0), scale=>1) regardless of whether we scaled or not.

Reload/Refresh tries to restore the old scroll and scale values, again, regardless of whether we scaled or not.

For other same page navigations, the "half position" you're seeing is probably that we set the scroll position to navigate to the anchor but do so for the layout viewport without resetting the visual viewport to (0, 0). We should probably do that but it's a minor issue.

There shouldn't be a difference in behavior depending on whether we scaled or not (and I can't see it). If there is, that's a regression.

I'm on Android Chrome 52.0.2743.98 / Nexus 5X, and navigate to http://yuri.twintail.org/chrome/reload/fragment.html
This page has a 'link to self html' anchor to navigate to the same page for the latter case.

Sorry, my report for Omnibox+Enter was wrong. But it just results are swapped. Still I can see the problem.

- Omnibox+Enter without any scale change => Reset scroll position and scale
- Omnibox+Enter after scale being changed => Don't reset scale, scroll position jumps to a half position

In some pages, they are managing initial scroll position by themselves. In such case, this problem may not happen.

Ok, maybe the pages I were looking at were managing it themselves. I've now reproduced the "half position" restore (seems we're resetting the main frame scroll offset but not the visual viewport) which is certainly a bug.

chaopeng@, please take a look when you have a chance.

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

commit 4521a9bb2402ebfffd709f02413ba3ec5a70de46
Author: chaopeng <chaopeng@chromium.org>
Date: Fri Sep 16 14:54:25 2016

Reset VisualViewport position after same page navigation

This issue can be reproduced using pinch zoom in Android, ChromeOS and Mac.

After navigating to the **exact** same page, we create a new FrameView but
reuse the VisualViewport, meaning its scroll position remains unchanged even
though it was relative to an old FrameView.

In this patch, we reset the VisualViewport position in Page::didCommitLoad
since prior to here we would overwrite the old history item.

BUG= 642279 

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

[add] https://crrev.com/4521a9bb2402ebfffd709f02413ba3ec5a70de46/third_party/WebKit/LayoutTests/fast/scrolling/same-page-navigate.html
[modify] https://crrev.com/4521a9bb2402ebfffd709f02413ba3ec5a70de46/third_party/WebKit/Source/core/page/Page.cpp
[modify] https://crrev.com/4521a9bb2402ebfffd709f02413ba3ec5a70de46/third_party/WebKit/Source/core/testing/Internals.cpp
[modify] https://crrev.com/4521a9bb2402ebfffd709f02413ba3ec5a70de46/third_party/WebKit/Source/core/testing/Internals.h
[modify] https://crrev.com/4521a9bb2402ebfffd709f02413ba3ec5a70de46/third_party/WebKit/Source/core/testing/Internals.idl

Doesn't look fixed to me, see attached.

Deleted: index.html 1.3 KB

index.html 1.3 KB View Download

Deleted: hash-test.mov 6.8 MB

hash-test.mov 6.8 MB Download

Thanks for the report. I think this is actually a separate bug due to the scroller being nested, this seems to work fine for the main window (e.g. https://en.wikipedia.org/wiki/Cat#Senses works correctly when reloaded or navigated).  I've filed your repro at  issue 656658