AppHistoryEntry.sameDocument

[frehner]

Forgive me if this is an easy/obvious question:

Currently sameDocument is defined as:

sameDocument: a boolean indicating whether this entry is for the current document, or whether navigating to it will require a full navigation (either from the network, or from the browser's back/forward cache). Note: for appHistory.current, this will always be true.

It's also said that

Note that you can check if the navigation will be same-document or cross-document via event.destination.sameDocument

In the docs about same-document navigations, it says

Same-document navigations can happen due to: ... Intercepting a cross-document navigation using the appHistory object's navigate event, and calling event.respondWith()

With that in mind, should sameDocument always change to true (if it wasn't already) in the complete event sequence steps ix and x where the promise is resolved?

Thanks in advance for your patience. 🙂

[domenic]

I think it would change a bit earlier, the moment respondWith() is called. But yeah, that's the idea.

[frehner]

so I went and reread the actual spec text, and found this line:

Let isSameDocument be true if specified browsing context’s active document equals specified entry’s document; otherwise, false.

if I'm understanding that correctly, that actually just says that when you push the browser back button, sameDocument = true when the url you're navigating to is the same as the previous entry's url. Does that sound right?

---

you can ignore the text below now, probably. I'll keep it here for reference, but I think my edit above is much more clear.

---

a related question, regarding same-document vs cross-document navigations:

in your example here https://gigantic-honored-octagon.glitch.me it says

You can use either your browser back button, or the following link, to go back to index.html. Either will perform a single-page navigation, in browsers that support app history!

Normally clicking the back button to go back to /index.html (from /subpage.html) would be a cross-document navigation without appHistory.

But because appHistory intercepted the navigation from /index to /subpage and respondWith was called, it was a same-document navigation.

So when the browser UI's back button is clicked, appHistory must first check the entries list and see if that url exists (and double check sameDocument === true) to determine if it will fire navigate, since cross-document browser UI interactions don't fire navigate according to the table in this section.

And in your example, it would find that URL and see that sameDocument === true, so it will fire navigate.

Does all of that sound right?

If it is, the type of navigation would be caused by a appHistory.go() and not appHistory.push(), correct? (i.e. we're not adding to the entires; we're navigating backwards to an existing one)

Sorry, that's a long one. I just wanted to be sure I understood as I worked on back-button event handling. 😊

[domenic]

if I'm understanding that correctly, that actually just says that when you push the browser back button, sameDocument = true when the url you're navigating to is the same as the previous entry's url. Does that sound right?

You can have two different URLs with the same document. That happens any time there's a single-page navigation, e.g.:

• You're on /a and you do history.pushState(null, null, "/b"). You now have two history entries, with (document1, /a) and (document1, /b).

• You're on /a and you get navigated to /a#test

• You're on /a and you start a navigation to /b which app history intercepts and does respondWith() on.

See also https://github.com/WICG/app-history#appendix-types-of-navigations which tries to go into this in some more detail.

[domenic]

Let's fold this into #97. The current direction we're thinking there is that event.destination.sameDocument will not change.