"update the session history with the new page" for a page reload or location.reload()

[toyoshim]

https://html.spec.whatwg.org/multipage/browsers.html#dom-location-reload
It says

Navigate the browsing context to the document's URL with the exceptions enabled flag set and replacement enabled. The source browsing context must be the browsing context being navigated. This is a reload-triggered navigation. Rethrow any exceptions.

https://html.spec.whatwg.org/multipage/browsers.html#update-the-session-history-with-the-new-page
In the step 2, it says

If the navigation was initiated for entry update of an entry

1. Replace the Document of the entry being updated, and any other entries that referenced the same document as that entry, with the new Document.
2. Traverse the history to the new entry.

Otherwise

1. Remove all the entries in the browsing context's session history after the current entry. If the current entry is the last entry in the session history, then no entries are removed.
2. Append a new entry at the end of the History object representing the new resource and its Document object, related state, and the default scroll restoration mode of "auto".
3. Traverse the history to the new entry. If the navigation was initiated with replacement enabled, then the traversal must itself be initiated with replacement enabled.

Should we assume Navigate with replacement enabled means the case of navigation was initiated for entry update here?

In the spec, navigation was initiated for entry update is referenced only from history traversal algorithm that isn't for reload.

If we follow the latter Otherwise case for reload, UA needs to remove all succeeding entries from the session history. That isn't a behavior existing UAs implement and users expect.

[domenic]

Hmm. This does look like a spec bug to me, but I'd like @annevk to confirm.

To reiterate what the OP posted:

• location.reload() navigates the page with replacement enabled
• This eventually lands on update the session history with the new page
• At that point "If the navigation was initiated for entry update of an entry" seems to be false.
• So per spec we are required to clear subsequent entries from window.history
• But in browsers this does not happen: go to a few pages, press back a few times, check window.history.length, do location.reload(), and check window.history.length again. It is the same.

I am a bit worried about what could have gone wrong here since the spec seems pretty explicit that "If the navigation was initiated for entry update of an entry" cannot be true if replacement is enabled: it has a non-normative note saying:

This can only happen if the entry being updated is not the current entry, and can never happen with replacement enabled. (It happens when the user tried to traverse to a session history entry that no longer had a Document object.)

I wonder if "update the session history with the new page" is not supposed to be invoked here? Maybe something got lost in the recent refactoring...

[annevk]

Looking through https://whatwg.org/specs/web-apps/2009-10-27/ I think this has always been wrong. I suspect location.reload() should simply do an entry update. Also asking @smaug---- to confirm to be extra sure.

[smaug----]

I think so
http://searchfox.org/mozilla-central/rev/6bb28c9903fe38d445cd2d3b17af4eabdade9335/docshell/base/nsDocShell.cpp#11490-11491
(that iframe case there is Gecko internal stuff. Though it is always a bit tricky to map implementation's session history to the spec)

[domenic]

@annevk, can you help fix this, or check my proposed fix? I think what you're saying is that:

• location.reload() should not perform a navigation with replacement enabled, but should instead perform an entry update for the current entry
• We should remove the clause in the non-normative note saying "This can only happen if the entry being updated is not the current entry"

Is that right?

[annevk]

Yeah, I think that's right based on what @smaug---- confirmed above.