wmlthomsonjr@Could you please provide us any sample test file or URL to triage the issue from test team end.

Thanks,

Sure
https://en.wikipedia.org/wiki/Chromium_(web_browser)#Snapshots

That should take you to the snapshot section of that page. Scroll to the top or bottom. Then refresh and it does not change position. At least it does not for me. I would assume on refresh it goes back to the Snapshots section rather than remaining where ever I last scrolled.

Hopefully this is not abnormal function on my system.... :)

Thank you for providing more feedback. Adding requester "kavvaru@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Tested in chrome # 58.0.3029.81 and Canary 60.0.3091.0 on Ubuntu 14.04 and able to reproduce the issue and observed same behaviour in other browser(Fire Fox) for provided URL in comment #3.

@Reporter: Could you please let me know if i have missed anything and if possible,Please check in other browsers and let us know the observations  and provide us with a another/different URL of the issue which would help us to triage the issue further.

Thanks in Advance.

While pressing refresh has no action in Firefox like Chromium. If I click in the URL (does not have to be selected) and hit enter in Firefox. It will reposition.

I visit same link as provided previously. I scroll to top or bottom. Then go click in the url area, then press enter. The page goes back to the snapshot section.

Doing the same in Chromium has no effect.

Thank you for providing more feedback. Adding requester "rbasuvula@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Tested the issue on chrome Stable #58.0.3029.96, Canary 60.0.3094.0 in Windows 10.0 & 7 and was able to reproduce the issue.

This is a Non-Regression issue since seeing this from M35 #35.0.1898.0, Making the status to Untriaged so that the issue would get addressed.

Note : Able to reproduce the issue in MAC 10.12 and Linux Ubuntu 14.04.

Thank you.

https://html.spec.whatwg.org/multipage/browsers.html#persisted-user-state-restoration

Reload navigation also needs to follow the "Persisted user state restoration" step as the spec defines. So, this is expected implementation.

Hitting the enter key in the Omnibox (URL editing UI) is an UI design matter. Today, Chrome adopts a normal reload if a user hits the enter without changing the URL in the box. So, this behavior is expected.

That is reloading from HISTORY, not when someone is literally still on the same page. This causes serious usability issues. That is a very twisted interpretation of that specification. Which is talking about reloading from history. NOT reloading a page you are LITERALLY still on....

That whole section deals on history Traversal. This has NOTHING to do with history, but the PRESENT. Nothing in there says that applies to refreshing a page. Nor does it say anything about hash tags.

I think you need to re-read. Which precedes the section quoted
https://html.spec.whatwg.org/multipage/browsers.html#scroll-to-fragid


I really cannot stand how Google uses standard compliance to justify broken behavior. Other browsers do not function that way. But this does not seem to be compliance but strange interpretation.

IIUC, the "navigate to that fragment" algorithm should be processed only when the navigation is not reload-triggered navigation, and so on as "Navigating across documents" algorithm defines.

In Chrome, entering new URL in the omnibox is handled as a new navigation, and entering the same URL there is handled as a reload though Chrome handled it as a special reload variant, reload without scroll restoration, until several months ago. This is completely a browser UI matter that HTML5 spec does not define something. Also, this 'reload without scroll restoration' is completely a special behavior that HTML5 does not have.

We have so many reload variants and this is very minor use case as you know only few people report it even after months passed. This will meat our criteria to change behaviors.

I think it is actually worthwhile discussing the use case of "hit enter in the omnibox, without changing the URL, so I can get back to the right place in the page referred by the fragment". If you load a big page (take the HMLT5 spec as an example), which you scroll around to learn about different parts, then want to go back to where you started, the only way is to navigate to the fragment. However, with the new behavior, this is impossible and lowers the usability of this scenario in Chrome.

This is resolved as WontFix, but adding creis@ who shares similar concerns as mine. I think it might be reasonable to implement this as the regular reload path we have currently, but clearing the PageState associated with the NavigationEntry. This will allow us to not keep any of the previous scroll position or form data, which is arguably what the user intents if they just press enter in the omnibox - load just that URL from scratch.

If we introduce a reload with resetting PageState, that would be something new navigation that HTML spec does not define.

Today, navigation type is exposed to JavaScript via Navigation Timing API, and Service Worker want to consider what kind of navigation is performed for the current request. So, my concern is adding new kind of navigation makes it difficult to other related specs consistent.

If users want to use re-entering to reset the scroll position, how about handling it as a new navigation even the URL is completely same. This will reset referrer, form, and scroll position, and add new entry to the history. But sounds like what users want?

Also, my another preference is just to set window.history.scrollRestration to "manual".
https://html.spec.whatwg.org/multipage/browsers.html#the-history-interface
My expectation here is that it does not restore scroll position and scroll to the anchor point. But current our implementation is just not to restore the position, and does not scroll to the anchor point but stick to the top position. AFAIK, specs do not clarify this use case. I quickly check Firefox implementation, but it goes to the anchor point on reload when the scrollRestoration is "manual".

I think all of what you describe about resetting everything. Occurs when one opens a new tab to copy/paste the same URL. In order to get back to the anchored/fragment section of the page.

I am not sure anchors are used much in forms. But if a form was on the page, it would not be desirable for that to be reset. I can see the dilemma there. Though with regard to history, opening a new tab and entering in the same url is basically the same as described. A new entry.

If it was a big page with a form. One could get lost just the same reading instructions and having to scroll up and down a lot. Just to get back to say the anchored/fragment portion where the form is in the page.

Looks like a History and Navigation issue, rather than Loading. Relabeling.

I am no longer using Chrome/Chromium so I will be unable to test or comment on this bug any further. Life is to short. This issue, another with sticky scrollbars, and my growing dislike and distaste for anything having to do with Google.

Fix this or not, its moot to me, may be of concern to others. Either way I have little hope Google with address. I have moved on. Thanks bye!

I just tried and refreshing the page (focus omnibox -> enter, pull to refresh, and refresh menu button) and they all reposition the page to the anchor location.

Sigh...only tested on Android not desktop.  And I got different behavior on desktop that wasn't fixed.  Should I look at the site implementation or do we think it would be different across mobile and desktop?

Hi. Looks like this issue has regressed in recent builds or wasn't fixed in desktop builds or I'm hitting a particularly tricky situation with this specific page.

Steps to reproduce:
1. Visit https://www.oracle.com/technetwork/security-advisory/cpujul2017-3236622.html#AppendixOVIR
2. Observe that initial positioning works properly. Page is anchored at "Appendix - Oracle Linux and Virtualization Oracle Virtualization Executive Summary" part of the page
3. Focus on the omnibox and press Enter

Expected result:
1. Page is repositioned to the expected anchor location (described in step #2)

Actual result:
1. Page is repositioned to the last position it was at, e.g. if you scroll all the way up on that page and then focus on omnibox -> press enter you will still end up on the top part of the page after page reload.

Does this work in other browsers?
Yes, in Firefox and Edge but only "focus on the address bar and press Enter" way. Simple refresh of the page doesn't reposition the page back to expected position in Firefox and Edge.

Chrome version: 70.0.3538.77 (Official Build) (64-bit). Also reproducible in 72.0.3606.0 (Official Build) canary (64-bit)

Thanks.