The title is somewhat misleading; perhaps it should have stated: "when same URL is typed in address bar".

Demo here: https://output.jsbin.com/texeqag/quiet

From the spec:

TYPE_RELOAD
Navigation through the reload operation or the location.reload() method.

https://www.w3.org/TR/navigation-timing/#dom-performancenavigation-typereload

Tentatively labelling Good First Bug.

   As the spec said, we should treat the navigation as navigate except TYPE_RELOAD and TYPE_BACK_FORWARD, so when NavigateWithoutEntry we donn't need check whether this navigation shouled be treaded as reload. right? 

Internally, we treat this case as a reload of sorts (namely, we treat it as equivalent to pressing the reload button for the purpose of cache policy). https://bugs.chromium.org/p/chromium/issues/detail?id=536102 discusses a potential cleanup of this logic.

As long as that logic is in place, this case should probably report TYPE_RELOAD. After all, the cache policy is like a reload, and that means for performance purposes, it might as well have been a reload. Also, the spec uses the ambiguous terminology "reload operation". It's arguably up to the browser to decide which UI actions are "reload operations" and which are normal navigations.

Basically, I think either (1) this is working as intended, and we should fix issue 536102 to make the address-bar-navigation-to-same-url case cleaner and treat it as a reload throughout the codebase, or (2) we should treat address-bar-navigation-to-same-url as a normal navigation through the codebase, and not give it any special caching behavior (which may or may not cause user confusion).

Adding dcheng and creis in case they have thoughts.

From the spec: 

TYPE_NAVIGATE:
Navigation started by clicking on a link, or entering the URL in the user agent's address bar, or form submission, or initializing through a script operation other than the ones used by TYPE_RELOAD and TYPE_BACK_FORWARD as listed below.

My reading of the spec is that any navigation from the address bar MUST be TYPE_NAVIGATE, which means that we are violating the spec.

It's possible we should instead update the spec though.

I perhaps shouldn't have labelled this GoodFirstBug - sorry!

+igrigorik, +yoav for whether we should update the spec to allow URL bar driven navigations to be considered reloads.

I think it's curious this type of load is handled internally as a reload (when it comes to caching).

As a web developer, I often need to reload a URL without redoing a POST request made prior. Thus, I select the URL in the omnibar and press enter, assuming this would do a clean GET to the URL. (I.e. instead of press reload, which would redo a POST if the last request was POST.) Now I learn the browser internally does a reload? What does that mean?? Is _that_ spec?

Navigation to a samepage  may be treated as a reload only when it's a GET reqeust for now. it will be transmit to a standard request (maybe navigate) when it's a POST request

If TYPE_RELOAD is currently being used by applications to determine whether or not a request was cached (albeit in a unspecced way), it could be worthwhile to keep the current behaviour. However, it should be much more tractable to determine that by checking that the transfer size is zero / less than the encoded body size (https://www.w3.org/TR/resource-timing-2/#dom-performanceresourcetiming-transfersize).

That being said, I think that returning TYPE_NAVIGATE for correctness makes sense here. This is theoretically more useful for sites that want to couple their own invalidation semantics with reload events. However, I'm not sure how often this is done in practice.

Thoughts?

(FWIW, Firefox does not skip the cache on same-URL navigations, and returns TYPE_NAVIGATE as one might expect)

> That being said, I think that returning TYPE_NAVIGATE for correctness makes sense here. This is theoretically more useful for sites that want to couple their own invalidation semantics with reload events. However, I'm not sure how often this is done in practice.

Even if it might not be done _often_, it is the _only_ way to do it! Correct?
Frankly, I would be surprised if it isn't done often. I personally would like to be 100% in control of having working, intuitive back button functionality on my sites.

Also applies to reload button.