Confirmed that this is a behavior change, though I'm not as convinced the new behavior is wrong.  But it's definitely true that in e.g. Chrome 52, F5 restored your scroll position and enter in the omnibox didn't.

Retriaging as a navigation stack issue; the omnibox code here hasn't changed.

Hmm.  Blink already interprets "enter in the omnibox" as a reload, leading to some complexity in the code that we're hoping to remove (issue 536102).  The strange thing is, that work hasn't landed-- shess@ has a CL in progress at https://codereview.chromium.org/2381503003/.

Given the timing, I suppose it's possible that this could be caused by the new navigation path we enabled in M54, but I'm not sure how at first glance.  Maybe a bisect would help confirm.

I'm guessing this is a question of whether the PageState is sent on the navigation or not, and I'm not sure what would cause it to be sent.  We should probably take a closer look to understand why it's happening and whether to consider it a bug.  (I'm guessing that we will want to fix it, since it's a bit odd from the user's perspective even if Blink treats it as a "reload.")

Thank you for the update.

If this is treated as a reload, are resources refreshed at all? My concern is with regards to data usage on a page reload.

Bisect info:
============
Good: 54.0.2840.18
Bad: 54.0.2840.21 

Omahaproxy UI CL:
https://chromium.googlesource.com/chromium/src/+log/54.0.2840.18..54.0.2840.21?pretty=fuller&n=10000

From the above CL suspecting the below:
Review URL: https://codereview.chromium.org/2326983002 .
toyoshim@ : Could you please take a look into this if its related to your change.

Its too late for M54, since the issue already exist in M53, please target to get a fix before M55 hits Stable.

Interesting!  r416855 intentionally restored this state to handle the F5 / reload case.

toyoshim@, did you intend for that CL to affect the enter-in-address bar case as well?  I'm wondering if it's worth making an exception for that (and if issue 536102 should also take that into account).

Wrong Scott.

Comment 8:  Oops!  Sorry about that.  I did mean you in comment 3.  :)

toyoshim@, could you please reply to comment #7. 

**** Bulk edit -  please ignore if not applicable ****

A friendly reminder that M55 Stable is launch is coming soon! Your bug is labelled as Stable ReleaseBlock, pls make sure to land the fix and get it merged into the release branch ASAP so it gets enough baking time in Beta (before Stable promotion). Thank you!

Also due to Thanksgiving holidays in US, please make sure all fixes are ready and merged to M55 latest by 5:00 PM PT Friday, 11/18/16.

>#7
Yes, this is intentional change.
I'm removing reload variations step by step, and eventually Chrome will have only two variations of reloads, main resource only reload and full reload.

"Enter in omnibox for the same URL" is classified into the main resource only reload. That forces to revalidate main resource, and restore user states as a reload button does.

HTML spec does not have a clear definition about the same page navigation, and I discuss it in parallel.

Also answer for the original report is here:

> If it is by design, is there a flag that can reverse the behaviour? (I cannot find such flag.) If there isn't a flag, can one be added?

Actually, we have a flag that can revert this change, but it also reverts new faster reload implementation. And unfortunately, we will remove this flag soon.

Now browsers have so many reload variants, and no one understand how different each reload is. This makes implementation complicated and makes it hard to maintain. This is the reason why I'm merging reload variants that have minor differences like this. So, I don't have a plan to keep current flag, or adding another flag.

#4, michaelarockett@
> If this is treated as a reload, are resources refreshed at all? 
Only main resource is revalidated. This hasn't been changed for a long time. This is one thing that differentiates the same page navigation from a normal navigation. Also, it does not add a new navigation entry to the history. That's another difference. So, the same page navigation has behaved as a kind of light reload for a long time.


#6, ligimole@
> since the issue already exist in M53
Is this true?

New reload is managed via field study flag, and it was enabled only for 54.0.2840.27 and later versions on Beta, and all 54.* on Stable. The behavior change in this report is bound to the same flag, and I believe this should not happen on m53 unless you explicitly enable it.
But it's also true that this behavior has been in the current Stable for weeks, and we haven't seen any strong push back until now.

Sorry for my out-of-order replies, but I'd conclude this as 'WontFix' if there is no strong reason to revert.

Reply to comment #14. 

> since the issue already exist in M53
Is this true?

Sorry for the confusion , this is regression in M54.

#16, thanks.

So, now I'd close this bug as WontFix.
If someone can not agree, please feel free to reopen this, or file another bug with CC:toyoshim@.