In the last post, we talked about traversable navigables. I said I would delve a little deeper into these concepts to help you understand them at a more technically accurate level. You don’t need to read this post to understand browser storage at the level we need for the Privacy Sandbox. But I know many technical business people and product owners really like to understand the details. So if you are one of those people, this post is for you.
Documents and Session History Entries
We have talked a lot about session storage in past posts. But we have not really spoken in detail about what is stored there.
In order to do that, we must start with the concept of a document. I have used that term in past posts without defining it, because at a certain level everyone understands that a document is what they see on the web page. But that is not 100% technically accurate. For example, the Digital Video Ad Serving Template (VAST), an important standard for delivering video advertising into the browser (which we will discuss at length in regards to limitations of fenced frames and the Protected Audience API), contains the concept of a VAST document - the template - that contains information about the video to allow the publisher to present the video. You will hear developers over-and-over again in meetings (see this discussion) use the term “VAST document” instead of “VAST template”. While this is not the same conceptually as an HTML document, it is an extension of the concept to video. We will see this broader usage again in other contexts.
A document is a formal term in the HTML specification for a document object. It is represented by a concept you also have already been exposed to earlier - the Document Object Model or DOM. In essence, an HTML document is a text-based file that acts as the blueprint for a webpage. It uses elements and attributes (which I will not discuss here as now we are getting too far into the weeds) to define the structure and content, which the browser interprets using the DOM to display the webpage as you see it.
Three important items are set when the document is created:
- The document’s URL.
- The document’s origin.
- A document’s session history entry.
The browser fetches the given URL from the network and uses it to populate a new session history entry with the newly created document.
A document’s origin is the same origin we have discussed as the key used to partition storage. The origin is the top level domain (TLD) of the site/document. That is to say if you open www.example.com/sports_home, the origin is www.example.com and the key is a unique number tied to the TLD. Now there are subtleties I am not covering here - such as the fact that a document’s origin can differ from the current URL’s origin. But to keep things simple, we’ll stick to the basic notion that the origin is set when you open a document from a site that you are visiting for the first time in a session.
The document’s session history is stored, as you might expect, in the browser’s session storage. You can think of a session history entry as a snapshot of the web pages you have accessed during your current browsing session. They are essentially bookmarks that contain information that simplifies recreating a page should you open it again.
A session history is a formal code structure that contains ten items - including its URL, its document state, and its scroll position. The document state contains information to allow the browser to recreate the page quickly - say when you leave it and go back to it via the back button, or if the document is removed from the cache to avoid hitting storage limits (a familiar notion to you now if you’ve read prior posts). There is a cute term about cache here I just have to mention - the bfcache. The formal term is back-forward cache. This is a cache where browsers store the session history and the document state. But developer’s have renamed it “blazingly fast cache.” Leave it to developers to create cool names for what is otherwise a boring notion. Ya gotta love em.
There is also the notion of an active session history. This is the session history structure for the current document (web page) you are viewing.
Navigables
I could dig even deeper into documents and session histories but that’s all we need to know for now to move onto the next topic: navigables.
The technical definition of a navigable is an item that presents a document to the user via its active session history entry. You can think of it as a browser tab, but it isn’t actually a tab itself. It is a concept related to the browser’s history and navigation capabilities.
Figure 1 - The Relationship Between a Browser Tab, a Navigable, and the Navigation History File
Tabs are the visual representations of open webpages in your browser window. Navigables, on the other hand, are the underlying entries in your browsing history that enable you to navigate back and forth between those tabbed web pages (the ones you can revisit). It basically contains all the information needed to navigate to and from a particular web page. You can think of it like a bookmark. When you click the back or forward button in your browser, the browser uses navigables to find the previous webpage you visited in your session and display it. The navigable acts like a reference point for the browser to know where to take you back to.
Figure 2 - Elements of a Navigable and a Traversable Navigable
Navigables also have data structures consisting, in this case, of six items (Figure 2). They are
- A Navigable ID. This is a unique identifier assigned by the browser internally to each navigable. It's not directly exposed to developers and is used by the browser to manage navigables within your browsing history.
- A Parent Navigable. The parent element points to the parent navigable in the browsing history. This creates a hierarchical structure that reflects how you navigate between web pages.
Imagine you visit web page A, then B, and then C. The navigable for web page C would have web page B as its parent navigable, indicating you navigated to C from B. The navigable for webpage B might have webpage A as its parent, and the navigable for webpage A might have a parent of null (since it was the starting point).
- A Current Session History Entry.This element references the corresponding session history entry for the navigable. When multiple tabs are open, each tab has a separate current session history entry
- An Active Session History Entry. This element references the currently active session history entry. There can only be one active navigable/session history entry at a time. When multiple tabs are open, the active session history entry is for the webpage you're currently viewing.
- is closing Status. is status is a boolean flag indicating whether the webpage associated with the navigable is in the process of closing. It's initially set to false. When you close a tab or window, the browser might set this flag to true for the corresponding navigable to indicate that the webpage is being unloaded or closed. This can be used internally by the browser to manage resources associated with the closing webpage.
These elements within a navigable work together to provide the browser with the information it needs to manage your browsing history and navigation. The id uniquely identifies the navigable, the parent reflects navigation flow, the current session history entry points to the webpage details, the active session history entry indicates the current webpage is the focus, and the is closing flag helps manage resources upon webpage closure. Developers don't directly interact with these elements, but the browser uses them behind the scenes for efficient navigation and history management.
Traversable Navigables
A traversable navigable is a special type of navigable that has additional capabilities. It builds upon the foundation of a navigable, adding functionalities related to session history management and navigation control. If the navigable is a bookmark, the traversable navigable provides the information needed to move between bookmarks.
Having two concepts creates a clear separation between the basic representation of a visited webpage (navigable) and the more complex functionalities like session history management and navigation control (traversable navigable). This separation enables the browser to handle different types of browsing contexts (e.g., tabs, windows, frames) more efficiently. Not all navigables need full session history control, so traversable navigables can be used where necessary.
Let’s use an example to clarify the concepts. Imagine you open two tabs in your browser:
- Tab 1: Navigates to example.com (becomes a navigable). We will identify this as the main browser window.
- Tab 2: Navigates to subdomain.example.com (becomes another navigable).
Both tabs (navigables) are managed by the browser. They have unique IDs, can track their parent (likely the initial browser window), and point to their corresponding session history entries with details about the web pages.
However, only the main browser window might be a traversable navigable. This traversable navigable would then control the session history for both tabs (example.com and subdomain.example.com), allowing you to navigate back and forth between them using the browser's history buttons. It might also manage the bfcache for these pages.
The traversable navigable adds several elements to the elements contained in the navigable:
- A Current Session History Step. This element keeps track of the current position within the traversable navigable's session history. It's a number starting from 0, and it indicates the specific session history entry that is considered the "current" page within the context of the traversable navigable.
- Session History Entries. This list stores all the session history entries associated with the traversable navigable. It essentially acts as a log of all the webpages you've visited within the context managed by that traversable navigable. This list is crucial for the traversable navigable to manage the session history for itself and potentially its descendants (other navigables within its control, see below). The browser uses this list to provide functionalities like the back/forward buttons and potentially the bfcache.
- A Session History Traversal Queue. This is a standard queue data structure. The browser uses it to manage the order of navigation steps (back/forward) within the session history. Imagine a line of steps, where you add new steps (forward navigation) at the back and remove steps (backward navigation) from the front.
- A Running Nested Apply History Step. A bit too deep for us, but mentioned for technical accuracy and completeness. This flag helps the browser avoid conflicts or unexpected behavior when multiple navigation actions happen within a nested browsing context (frames or iframes).
- A System Visibility State. This is a boolean flag which is set to either hidden or visible. This element tracks whether the browser window or tab associated with the traversable navigable is currently visible or hidden. A hidden state occurs when you minimize the window or switch to another tab. The visibility state can be used by the browser to optimize resource management or handle situations where a webpage is not actively being viewed. For instance, the browser might pause timers or animations on a hidden webpage to conserve resources.
Child Navigables and Navigable Containers
Traversable navigables, as objects, can live in a hierarchy. Four concepts: top-level navigables, child navigables, navigable containers, and content navigables all work together to represent the hierarchical structure of your browsing history and the relationships between web pages within that history. The relationships between these concepts are shown in Figure 3.
Figure 3 - The Relationship Hierarchy Between Traversal Navigable Types
A top-level traversable is the top level of the hierarchy. All traversable navigables are top-level traversables because they are the root element in the hierarchy.
Child navigables are traversable navigables that are nested or embedded within a top-level navigable or another child navigable. This creates a hierarchical parent-child relationship. An iFrame within a web page could be represented by a child navigable that inherits its session history management from its parent (the top-level navigable or another child navigable). They can also have their own limited navigation control within the frame/iframe.
Content navigables represent the actual web pages themselves within this hierarchy. They don't have session history management capabilities - and thus are not “pure” navigables by the definition of the object - but are essential elements within the structure.
Navigable containers are a type of navigable that can group other navigables (often child navigables). They might be used for specific browsing contexts where managing a group of related web pages together is beneficial.
Well I expect that’s enough technical detail to hold you for some time. So I’ll stop here. Again, it was probably too much detail for the average reader, but it was fun for me to write about and I do not doubt that more than a few folks will enjoy this detour into browser mechanics.
NEXT UP: Browser Storage After The Sandbox (FINALLY!)