Repository navigation
AppHistoryEntry.sameDocument #70
Description
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. 🙂
Activity
domenic commentedon Mar 15, 2021
I think it would change a bit earlier, the moment respondWith() is called. But yeah, that's the idea.
frehner commentedon Mar 18, 2021
so I went and reread the actual spec text, and found this line:
if I'm understanding that correctly, that actually just says that when you push the browser back button,
sameDocument = truewhen 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
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
/indexto/subpageandrespondWithwas 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 firenavigate, since cross-document browser UI interactions don't firenavigateaccording to the table in this section.And in your example, it would find that URL and see that
sameDocument === true, so it will firenavigate.Does all of that sound right?
If it is, the type of navigation would be caused by a
appHistory.go()and notappHistory.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 commentedon Mar 18, 2021
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
/aand you dohistory.pushState(null, null, "/b"). You now have two history entries, with (document1, /a) and (document1, /b).You're on
/aand you get navigated to/a#testYou're on
/aand you start a navigation to/bwhich app history intercepts and doesrespondWith()on.See also https://github.com/WICG/app-history#appendix-types-of-navigations which tries to go into this in some more detail.
domenic commentedon Apr 16, 2021
Let's fold this into #97. The current direction we're thinking there is that
event.destination.sameDocumentwill not change.