Should "reload-triggered navigation" be more strictly defined?

[yoavweiss]

In w3c/navigation-timing#116 we have an issue where it's unclear if certain browser UX gestures (e.g. focusing the URL bar and hitting enter) should be considered a "reload" or not. Ideally, I'd like Navigation Timing to just use the "reload triggered navigation" flag to determine the navigation type.

While discussing this issue, we realized that many aspects of reloading are not tightly defined. E.g. there's no "force reload" definition in HTML (or at least we failed to find one), no clear mapping from UX gestures to navigation types, etc.

Since different browsers do different things here, should it be more strictly defined? Or should this live in the realm of user agent UX, and not be further standardized?

/cc @rniwa @npm1

[Zirro]

I'm aware of two behaviours which differ based on whether the request is considered a reload in the specification. They are whether forms get resubmitted and if the referrer from the previous request is included in the 'reload request'.

Browsers also have their own minor UI/UX differences such as whether input in unsubmitted forms gets restored after the navigation. Firefox restores it when the reload button is used but not when hitting enter on the URL bar, while Safari restores it in both cases and Chrome clears it in both cases.

These differences can be useful in practice to either precisely repeat the same navigation as before (in cases where the page fails to load for example), or to discard unwanted input from the current page and start over with a blank slate. The ability to (re)navigate without keeping the referrer from the previous request is also helpful on pages that serve different content based on this header.

I believe these differences make the actions sufficiently different that hitting enter in the URL bar should be considered a "fresh load" rather than a reload, from both the browser and the site's perspective.

[annevk]

HTML should at least define infrastructure for location.reload() and navigating to the same URL. What UI maps to these is up to the implementation. "Hard reload" is mostly a developer-oriented feature that has even less need to be standardized I think and might affect all kinds of things.

[annevk]

Youenn reminded me there's a good reason to standardize this. It ends up changing the request's cache mode which is a web-exposed field (through request.cache in service workers).

For a "hard reload" browsers will use the "reload" state for the navigation and subsequent subresource fetches. There's a subtle difference reportedly: fetches initiated during the load event will have "reload" in Chromium, but "default" in WebKit (soon, intentionally) and Gecko. After that everyone uses "default".

There's corresponding discussion in whatwg/fetch#289.