1. 7.4 Navigation and session history
      1. 7.4.1 Session history
        1. 7.4.1.1 Session history entries
        2. 7.4.1.2 Document state
        3. 7.4.1.3 Centralized modifications of session history
        4. 7.4.1.4 Low-level operations on session history
      2. 7.4.2 Navigation
        1. 7.4.2.1 Supporting concepts
        2. 7.4.2.2 Beginning navigation
        3. 7.4.2.3 Ending navigation
          1. 7.4.2.3.1 The usual cross-document navigation case
          2. 7.4.2.3.2 The javascript: URL special case
          3. 7.4.2.3.3 Fragment navigations
          4. 7.4.2.3.4 Non-fetch schemes and external software
        4. 7.4.2.4 Preventing navigation
        5. 7.4.2.5 Aborting navigation
      3. 7.4.3 Reloading and traversing
      4. 7.4.4 Non-fragment synchronous "navigations"
      5. 7.4.5 Populating a session history entry
      6. 7.4.6 Applying the history step
        1. 7.4.6.1 Updating the traversable
        2. 7.4.6.2 Updating the document
        3. 7.4.6.3 Revealing the document
        4. 7.4.6.4 Scrolling to a fragment
        5. 7.4.6.5 Persisted history entry state

Welcome to the dragon's maw. Navigation, session history, and the traversal through that session history are some of the most complex parts of this standard.

The basic concept may not seem so difficult:

You can see some of the intertwined complexity peeking through here, in how traversal can cause a navigation (i.e., a network fetch to a stored URL), and how a navigation necessarily needs to interface with the session history list to ensure that when it finishes the user is looking at the right thing. But the real problems come in with the various edge cases and interacting web platform features:

In what follows, we have attempted to guide the reader through these complexities by appropriately cordoning them off into labeled sections and algorithms, and giving appropriate words of introduction where possible. Nevertheless, if you wish to truly understand navigation and session history, the usual advice will be invaluable.

7.4.1 Session history

7.4.1.1 Session history entries

A session history entry is a struct with the following items:

To get a session history entry's document, return its document state's document.

Serialized state is a serialization (via StructuredSerializeForStorage) of an object representing a user interface state. We sometimes informally refer to "state objects", which are the objects representing user interface state supplied by the author, or alternately the objects created by deserializing (via StructuredDeserialize) serialized state.

Pages can add serialized state to the session history. These are then deserialized and returned to the script when the user (or script) goes back in the history, thus enabling authors to use the "navigation" metaphor even in one-page applications.

Serialized state is intended to be used for two main purposes: first, storing a preparsed description of the state in the URL so that in the simple case an author doesn't have to do the parsing (though one would still need the parsing for handling URLs passed around by users, so it's only a minor optimization). Second, so that the author can store state that one wouldn't store in the URL because it only applies to the current Document instance and it would have to be reconstructed if a new Document were opened.

An example of the latter would be something like keeping track of the precise coordinate from which a popup div was made to animate, so that if the user goes back, it can be made to animate to the same location. Or alternatively, it could be used to keep a pointer into a cache of data that would be fetched from the server based on the information in the URL, so that when going back and forward, the information doesn't have to be fetched again.

A scroll restoration mode indicates whether the user agent should restore the persisted scroll position (if any) when traversing to an entry. A scroll restoration mode is one of the following:

"auto"
The user agent is responsible for restoring the scroll position upon navigation.
"manual"
The page is responsible for restoring the scroll position and the user agent does not attempt to do so automatically
7.4.1.2 Document state

Document state holds state inside a session history entry regarding how to present and, if necessary, recreate, a Document. It has:

User agents may destroy a document and its descendants given the documents of document states with non-null documents, as long as the Document is not fully active.

Apart from that restriction, this standard does not specify when user agents should destroy the document stored in a document state, versus keeping it cached.

A POST resource has:

A nested history has:

This will later contain ways to identify a child navigable across reloads.

Several contiguous entries in a session history can share the same document state. This can occur when the initial entry is reached via normal navigation, and the following entry is added via history.pushState(). Or it can occur via navigation to a fragment.

All entries that share the same document state (and that are therefore merely different states of one particular document) are contiguous by construction.

A Document has a latest entry, a session history entry or null.

This is the entry that was most recently represented by a given Document. A single Document can represent many session history entries over time, as many contiguous session history entries can share the same document state as explained above.

7.4.1.3 Centralized modifications of session history

To maintain a single source of truth, all modifications to a traversable navigable's session history entries need to be synchronized. This is especially important due to how session history is influenced by all of the descendant navigables, and thus by multiple event loops. To accomplish this, we use the session history traversal parallel queue structure.

A session history traversal parallel queue is very similar to a parallel queue. It has an algorithm set, an ordered set.

The items in a session history traversal parallel queue's algorithm set are either algorithm steps, or synchronous navigation steps, which are a particular brand of algorithm steps involving a target navigable (a navigable).

To append session history traversal steps to a traversable navigable traversable given algorithm steps steps, append steps to traversable's session history traversal queue's algorithm set.

To append session history synchronous navigation steps involving a navigable targetNavigable to a traversable navigable traversable given algorithm steps steps, append steps as synchronous navigation steps targeting target navigable targetNavigable to traversable's session history traversal queue's algorithm set.

To start a new session history traversal parallel queue:

  1. Let sessionHistoryTraversalQueue be a new session history traversal parallel queue.

  2. Run the following steps in parallel:

    1. While true:

      1. If sessionHistoryTraversalQueue's algorithm set is empty, then continue.

      2. Let steps be the result of dequeuing from sessionHistoryTraversalQueue's algorithm set.

      3. Run steps.

  3. Return sessionHistoryTraversalQueue.

Synchronous navigation steps are tagged in the algorithm set to allow them to conditionally "jump the queue". This is handled within apply the history step.

Imagine the joint session history depicted by this Jake diagram:

01
top/a/b

And the following code runs at the top level:

history.back();
location.href = '#foo';

The desired result is:

012
top/a/b/b#foo

This isn't straightforward, as the sync navigation wins the race in terms of being observable, whereas the traversal wins the race in terms of queuing steps on the session history traversal parallel queue. To achieve this result, the following happens:

  1. history.back() appends steps intended to traverse by a delta of −1.

  2. location.href = '#foo' synchronously changes the active session history entry entry to a newly-created one, with the URL /b#foo, and appends synchronous steps to notify the central source of truth about that new entry. Note that this does not yet update the current session history entry, current session history step, or the session history entries list; those updates cannot be done synchronously, and instead must be done as part of the queued steps.

  3. On the session history traversal parallel queue, the steps queued by history.back() run:

    1. The target history step is determined to be 0: the current session history step (i.e., 1) plus the intended delta of −1.

    2. We enter the main apply the history step algorithm.

      The entry at step 0, for the /a URL, has its document populated.

      Meanwhile, the queue is checked for synchronous navigation steps. The steps queued by the location.href setter now run, and block the traversal from performing effects beyond document population (such as, unloading documents and switching active history entries) until they are finished. Those steps cause the following to happen:

      1. The entry with URL /b#foo is added, with its step determined to be 2: the current session history step (i.e., 1) plus 1.

      2. We fully switch to that newly added entry, including a nested call to apply the history step. This ultimately results in updating the document by dispatching events like hashchange.

      Only once that is all complete, and the /a history entry has been fully populated with a document, do we move on with applying the history step given the target step of 0.

      At this point, the Document with URL /b#foo unloads, and we finish moving to our target history step 0, which makes the entry with URL /a become the active session history entry and 0 become the current session history step.

Here is another more complex example, involving races between populating two different iframes, and a synchronous navigation once one of those iframes loads. We start with this setup:

012
top/t
frames[0]/i-0-a/i-0-b
frames[1]/i-1-a/i-1-b

and then call history.go(-2). The following then occurs:

  1. history.go(-2) appends steps intended to traverse by a delta of −2. Once those steps run:

    1. The target step is determined to be 2 + (−2) = 0.

    2. In parallel, the fetches are made to populate the two iframes, fetching /i-0-a and /i-1-a respectively.

      Meanwhile, the queue is checked for synchronous navigation steps. There aren't any right now.

    3. In the fetch race, the fetch for /i-0-a wins. We proceed onward to finish all of apply the history step's work for how the traversal impacts the frames[0] navigable, including updating its active session history entry to the entry with URL /i-0-a.

    4. Before the fetch for /i-1-a finishes, we reach the point where scripts may run for the newly-created document in the frames[0] navigable's active document. Some such script does run:

      location.href = '#foo'

      This synchronously changes the frames[0] navigable's active session history entry entry to a newly-created one, with the URL /i-0-a#foo, and appends synchronous steps to notify the central source of truth about that new entry.

      Unlike in the previous example, these synchronous steps do not "jump the queue" and update the traversable before we finish the fetch for /i-1-a. This is because the navigable in question, frames[0], has already been altered as part of the traversal, so we know that with the current session history step being 2, adding the new entry as a step 3 doesn't make sense.

    5. Once the fetch for /i-1-a finally finishes, we proceed to finish updating the frames[1] navigable for the traversal, including updating its active session history entry to the entry with URL /i-1-a.

    6. Now that both navigables have finished processing the traversal, we update the current session history step to the target step of 0.

  2. Now we can process the steps that were queued for the synchronous navigation:

    1. The /i-0-a#foo entry is added, with its step determined to be 1: the current session history step (i.e., 0) plus 1. This also clears existing forward history.

    2. We fully switch to that newly added entry, including calling apply the history step. This ultimately results in updating the document by dispatching events like hashchange, as well as updating the current session history step to the target step of 1.

The end result is:

01
top/t
frames[0]/i-0-a/i-0-a#foo
frames[1]/i-1-a
7.4.1.4 Low-level operations on session history

This section contains a miscellaneous grab-bag of operations that we perform throughout the standard when manipulating session history. The best way to get a sense of what they do is to look at their call sites.

To get session history entries of a navigable navigable:

  1. Let traversable be navigable's traversable navigable.

  2. Assert: this is running within traversable's session history traversal queue.

  3. If navigable is traversable, return traversable's session history entries.

  4. Let docStates be an empty ordered set of document states.

  5. For each entry of traversable's session history entries, append entry's document state to docStates.

  6. For each docState of docStates:

    1. For each nestedHistory of docState's nested histories:

      1. If nestedHistory's id equals navigable's id, return nestedHistory's entries.

      2. For each entry of nestedHistory's entries, append entry's document state to docStates.

  7. Assert: this step is not reached.

To get session history entries for the navigation API of a navigable navigable given an integer targetStep:

  1. Let rawEntries be the result of getting session history entries for navigable.

  2. Let entriesForNavigationAPI be a new empty list.

  3. Let startingIndex be the index of the session history entry in rawEntries who has the greatest step less than or equal to targetStep.

    See this example to understand why it's the greatest step less than or equal to targetStep.

  4. Append rawEntries[startingIndex] to entriesForNavigationAPI.

  5. Let startingOrigin be rawEntries[startingIndex]'s document state's origin.

  6. Let i be startingIndex − 1.

  7. While i > 0:

    1. If rawEntries[i]'s document state's origin is not same origin with startingOrigin, then break.

    2. Prepend rawEntries[i] to entriesForNavigationAPI.

    3. Set i to i − 1.

  8. Set i to startingIndex + 1.

  9. While i < rawEntries's size:

    1. If rawEntries[i]'s document state's origin is not same origin with startingOrigin, then break.

    2. Append rawEntries[i] to entriesForNavigationAPI.

    3. Set i to i + 1.

  10. Return entriesForNavigationAPI.

To clear the forward session history of a traversable navigable navigable:

  1. Assert: this is running within navigable's session history traversal queue.

  2. Let step be the navigable's current session history step.

  3. Let entryLists be the ordered set « navigable's session history entries ».

  4. For each entryList of entryLists:

    1. Remove every session history entry from entryList that has a step greater than step.

    2. For each entry of entryList:

      1. For each nestedHistory of entry's document state's nested histories, append nestedHistory's entries list to entryLists.

To get all used history steps that are part of traversable navigable traversable:

  1. Assert: this is running within traversable's session history traversal queue.

  2. Let steps be an empty ordered set of non-negative integers.

  3. Let entryLists be the ordered set « traversable's session history entries ».

  4. For each entryList of entryLists:

    1. For each entry of entryList:

      1. Append entry's step to steps.

      2. For each nestedHistory of entry's document state's nested histories, append nestedHistory's entries list to entryLists.

  5. Return steps, sorted.

Certain actions cause a navigable to navigate to a new resource.

For example, following a hyperlink, form submission, and the window.open() and location.assign() methods can all cause navigation.

Although in this standard the word "navigation" refers specifically to the navigate algorithm, this doesn't always line up with web developer or user perceptions. For example:

Before we can jump into the navigation algorithm itself, we need to establish several important structures that it uses.

The source snapshot params struct is used to capture data from a Document initiating a navigation. It is snapshotted at the beginning of a navigation and used throughout the navigation's lifetime. It has the following items:

has transient activation
a boolean
sandboxing flags
a sandboxing flag set
allows downloading
a boolean
fetch client
an environment settings object or null, only to be used as a request client
source policy container
a policy container

To snapshot source snapshot params given a Document-or-null sourceDocument:

  1. If sourceDocument is null, then return a new source snapshot params with

    has transient activation
    true
    sandboxing flags
    an empty sandboxing flag set
    allows downloading
    true
    fetch client
    null
    source policy container
    a new policy container

    This only occurs in the case of a browser UI-initiated navigation.

  2. Return a new source snapshot params with

    has transient activation
    true if sourceDocument's relevant global object has transient activation; otherwise false
    sandboxing flags
    sourceDocument's active sandboxing flag set
    allows downloading
    false if sourceDocument's active sandboxing flag set has the sandboxed downloads browsing context flag set; otherwise true
    fetch client
    sourceDocument's relevant settings object
    source policy container
    a clone of sourceDocument's policy container

The target snapshot params struct is used to capture data from a navigable being navigated. Like source snapshot params, it is snapshotted at the beginning of a navigation and used throughout the navigation's lifetime. It has the following items:

sandboxing flags
a sandboxing flag set

To snapshot target snapshot params given a navigable targetNavigable, return a new target snapshot params with sandboxing flags set to the result of determining the creation sandboxing flags given targetNavigable's active browsing context and targetNavigable's container.

Much of the navigation process is concerned with determining how to create a new Document, which ultimately happens in the create and initialize a Document object algorithm. The parameters to that algorithm are tracked via a navigation params struct, which has the following items:

id
null or a navigation ID
navigable
the navigable to be navigated
request
null or a request that started the navigation
response
a response that ultimately was navigated to (potentially a network error)
fetch controller
null or a fetch controller
commit early hints
null or an algorithm accepting a Document, once it has been created
COOP enforcement result
an opener policy enforcement result, used for reporting and potentially for causing a browsing context group switch
reserved environment
null or an environment reserved for the new Document
origin
an origin to use for the new Document
policy container
a policy container to use for the new Document
final sandboxing flag set
a sandboxing flag set to impose on the new Document
opener policy
an opener policy to use for the new Document
navigation timing type
a NavigationTimingType used for creating the navigation timing entry for the new Document
about base URL
a URL or null used to populate the new Document's about base URL
user involvement
a user navigation involvement used when obtaining a browsing context for the new Document

Once a navigation params struct is created, this standard does not mutate any of its items. They are only passed onward to other algorithms.

A navigation ID is a UUID string generated during navigation. It is used to interface with the WebDriver BiDi specification as well as to track the ongoing navigation. [WEBDRIVERBIDI]

After Document creation, the relevant traversable navigable's session history gets updated. The NavigationHistoryBehavior enumeration is used to indicate the desired type of session history update to the navigate algorithm. It is one of the following:

"push"
A regular navigation which adds a new session history entry, and will clear the forward session history.
"replace"
A navigation that will replace the active session history entry.
"auto"
The default value, which will be converted very early in the navigate algorithm into "push" or "replace". Usually it becomes "push", but under certain circumstances it becomes "replace" instead.

A history handling behavior is a NavigationHistoryBehavior that is either "push" or "replace", i.e., that has been resolved away from any initial "auto" value.

The navigation must be a replace, given a URL url and a Document document, if any of the following are true:

Other cases that often, but not always, force a "replace" navigation are:

Various parts of the platform track whether a user is involved in a navigation. A user navigation involvement is one of the following:

"browser UI"
The navigation was initiated by the user via browser UI mechanisms.
"activation"
The navigation was initiated by the user via the activation behavior of an element.
"none"
The navigation was not initiated by the user.

For convenience at certain call sites, the user navigation involvement for an Event event is defined as follows:

  1. Assert: this algorithm is being called as part of an activation behavior definition.

  2. Assert: event's type is "click".

  3. If event's isTrusted is initialized to true, then return "activation".

  4. Return "none".

7.4.2.2 Beginning navigation

To navigate a navigable navigable to a URL url using an optional Document-or-null sourceDocument (default null), with an optional POST resource, string, or null documentResource (default null), an optional response-or-null response (default null), an optional boolean exceptionsEnabled (default false), an optional NavigationHistoryBehavior historyHandling (default "auto"), an optional serialized state-or-null navigationAPIState (default null), an optional entry list or null formDataEntryList (default null), an optional referrer policy referrerPolicy (default the empty string), an optional user navigation involvement userInvolvement (default "none"), an optional Element sourceElement (default null), and an optional boolean initialInsertion (default false):

  1. Let cspNavigationType be "form-submission" if formDataEntryList is non-null; otherwise "other".

  2. Let sourceSnapshotParams be the result of snapshotting source snapshot params given sourceDocument.

  3. Let initiatorOriginSnapshot be a new opaque origin.

  4. Let initiatorBaseURLSnapshot be about:blank.

  5. If sourceDocument is null:

    1. Assert: userInvolvement is "browser UI".

    2. If url's scheme is "javascript", then set initiatorOriginSnapshot to navigable's active document's origin.

  6. Otherwise:

    1. Assert: userInvolvement is not "browser UI".

    2. Set initiatorOriginSnapshot to sourceDocument's origin.

    3. Set initiatorBaseURLSnapshot to sourceDocument's document base URL.

  7. Let navigationId be the result of generating a random UUID. [WEBCRYPTO]

  8. If the surrounding agent is equal to navigable's active document's relevant agent, then continue these steps. Otherwise, queue a global task on the navigation and traversal task source given navigable's active window to continue these steps.

    We do this because we are about to look at a lot of properties of navigable's active document, which are in theory only accessible over in the appropriate event loop. (But, we do not want to unconditionally queue a task, since — for example — same-event-loop fragment navigations need to take effect synchronously.)

    Another implementation strategy would be to replicate the relevant information across event loops, or into a canonical "browser process", so that it can be consulted without queueing a task. This could give different results than what we specify here in edge cases, where the relevant properties have changed over in the target event loop but not yet been replicated. Further testing is needed to determine which of these strategies best matches browser behavior, in such racy edge cases.

  9. If navigable's active document's unload counter is greater than 0, then invoke WebDriver BiDi navigation failed with navigable and a WebDriver BiDi navigation status whose id is navigationId, status is "canceled", and url is url, and return.

  10. Let container be navigable's container.

  11. If container is an iframe element and will lazy load element steps given container returns true, then stop intersection-observing a lazy loading element container and set container's lazy load resumption steps to null.

  12. If the navigation must be a replace given url and navigable's active document, then set historyHandling to "replace".

  13. If navigable's parent is non-null, then set navigable's is delaying load events to true.

  14. Let targetSnapshotParams be the result of snapshotting target snapshot params given navigable.

  15. Invoke WebDriver BiDi navigation started with navigable and a new WebDriver BiDi navigation status whose id is navigationId, status is "pending", and url is url.

  16. If navigable's ongoing navigation is "traversal", then:

    1. Invoke WebDriver BiDi navigation failed with navigable and a new WebDriver BiDi navigation status whose id is navigationId, status is "canceled", and url is url.

    2. Return.

    Any attempts to navigate a navigable that is currently traversing are ignored.

  17. Set the ongoing navigation for navigable to navigationId.

    This will have the effect of aborting other ongoing navigations of navigable, since at certain points during navigation changes to the ongoing navigation will cause further work to be abandoned.

  18. If url's scheme is "javascript", then:

    1. Queue a global task on the navigation and traversal task source given navigable's active window to navigate to a javascript: URL given navigable, url, historyHandling, sourceSnapshotParams, initiatorOriginSnapshot, userInvolvement, cspNavigationType, and initialInsertion.

    2. Return.

  19. If all of the following are true:

    then:

    1. Let navigation be navigable's active window's navigation API.

    2. Let entryListForFiring be formDataEntryList if documentResource is a POST resource; otherwise, null.

    3. Let navigationAPIStateForFiring be navigationAPIState if navigationAPIState is not null; otherwise, StructuredSerializeForStorage(undefined).

    4. Let continue be the result of firing a push/replace/reload navigate event at navigation with navigationType set to historyHandling, isSameDocument set to false, userInvolvement set to userInvolvement, sourceElement set to sourceElement, formDataEntryList set to entryListForFiring, destinationURL set to url, and navigationAPIState set to navigationAPIStateForFiring.

    5. If continue is false, then return.

    It is possible for navigations with userInvolvement of "browser UI" or initiated by a cross origin-domain sourceDocument to fire navigate events, if they go through the earlier navigate to a fragment path.

  20. If sourceDocument is navigable's container document, then reserve deferred fetch quota for navigable's container given url's origin.

  21. In parallel, run these steps:

    1. Let unloadPromptCanceled be the result of checking if unloading is canceled for navigable's active document's inclusive descendant navigables.

    2. If unloadPromptCanceled is not "continue", or navigable's ongoing navigation is no longer navigationId:

      1. Invoke WebDriver BiDi navigation failed with navigable and a new WebDriver BiDi navigation status whose id is navigationId, status is "canceled", and url is url.

      2. Abort these steps.

    3. Queue a global task on the navigation and traversal task source given navigable's active window to abort a document and its descendants given navigable's active document.

    4. If url matches about:blank or is about:srcdoc, then:

      1. Set documentState's origin to initiatorOriginSnapshot.

      2. Set documentState's about base URL to initiatorBaseURLSnapshot.

    5. Let historyEntry be a new session history entry, with its URL set to url and its document state set to documentState.

    6. Let navigationParams be null.

    7. If response is non-null:

      The navigate algorithm is only supplied with a response as part of the object and embed processing models, or for processing parts of multipart/x-mixed-replace responses after the initial response.

      1. Let sourcePolicyContainer be a clone of the sourceDocument's policy container, if sourceDocument is not null; otherwise null.

      2. Let policyContainer be the result of determining navigation params policy container given response's URL, null, sourcePolicyContainer, navigable's container document's policy container, and null.

      3. Let finalSandboxFlags be the union of targetSnapshotParams's sandboxing flags and policyContainer's CSP list's CSP-derived sandboxing flags.

      4. Let responseOrigin be the result of determining the origin given response's URL, finalSandboxFlags, and documentState's initiator origin.

      5. Let coop be a new opener policy.

      6. Let coopEnforcementResult be a new opener policy enforcement result with

        url
        response's URL
        origin
        responseOrigin
        opener policy
        coop

      7. Set navigationParams to a new navigation params, with

        id
        navigationId
        navigable
        navigable
        request
        null
        response
        response
        fetch controller
        null
        commit early hints
        null
        COOP enforcement result
        coopEnforcementResult
        reserved environment
        null
        origin
        responseOrigin
        policy container
        policyContainer
        final sandboxing flag set
        finalSandboxFlags
        opener policy
        coop
        navigation timing type
        "navigate"
        about base URL
        documentState's about base URL
        user involvement
        userInvolvement

    8. Attempt to populate the history entry's document for historyEntry, given navigable, "navigate", sourceSnapshotParams, targetSnapshotParams, userInvolvement, navigationId, navigationParams, cspNavigationType, with allowPOST set to true and completionSteps set to the following step:

      1. Append session history traversal steps to navigable's traversable to finalize a cross-document navigation given navigable, historyHandling, userInvolvement, and historyEntry.

7.4.2.3 Ending navigation

Although the usual cross-document navigation case will first foray into populating a session history entry with a Document, all navigations that don't get aborted will ultimately end up calling into one of the below algorithms.

7.4.2.3.1 The usual cross-document navigation case

To finalize a cross-document navigation given a navigable navigable, a history handling behavior historyHandling, a user navigation involvement userInvolvement, and a session history entry historyEntry:

  1. Assert: this is running on navigable's traversable navigable's session history traversal queue.

  2. Set navigable's is delaying load events to false.

  3. If historyEntry's document is null, then return.

    This means that attempting to populate the history entry's document ended up not creating a document, as a result of e.g., the navigation being canceled by a subsequent navigation, a 204 No Content response, etc.

  4. If all of the following are true:

    then set historyEntry's document state's navigable target name to the empty string.

  5. Let entryToReplace be navigable's active session history entry if historyHandling is "replace", otherwise null.

  6. Let traversable be navigable's traversable navigable.

  7. Let targetStep be null.

  8. Let targetEntries be the result of getting session history entries for navigable.

  9. If entryToReplace is null, then:

    1. Clear the forward session history of traversable.

    2. Set targetStep to traversable's current session history step + 1.

    3. Set historyEntry's step to targetStep.

    4. Append historyEntry to targetEntries.

    Otherwise:

    1. Replace entryToReplace with historyEntry in targetEntries.

    2. Set historyEntry's step to entryToReplace's step.

    3. If historyEntry's document state's origin is same origin with entryToReplace's document state's origin, then set historyEntry's navigation API key to entryToReplace's navigation API key.

    4. Set targetStep to traversable's current session history step.

  10. Apply the push/replace history step targetStep to traversable given historyHandling and userInvolvement.

7.4.2.3.2 The javascript: URL special case

javascript: URLs have a dedicated label on the issue tracker documenting various problems with their specification.

To navigate to a javascript: URL, given a navigable targetNavigable, a URL url, a history handling behavior historyHandling, a source snapshot params sourceSnapshotParams, an origin initiatorOrigin, a user navigation involvement userInvolvement, a string cspNavigationType, and a boolean initialInsertion:

  1. Assert: historyHandling is "replace".

  2. Set the ongoing navigation for targetNavigable to null.

  3. If initiatorOrigin is not same origin-domain with targetNavigable's active document's origin, then return.

  4. Let request be a new request whose URL is url and whose policy container is sourceSnapshotParams's source policy container.

    This is a synthetic request solely for plumbing into the next step. It will never hit the network.

  5. If the result of should navigation request of type be blocked by Content Security Policy? given request and cspNavigationType is "Blocked", then return. [CSP]

  6. Let newDocument be the result of evaluating a javascript: URL given targetNavigable, url, initiatorOrigin, and userInvolvement.

  7. If newDocument is null:

    1. If initialInsertion is true and targetNavigable's active document's is initial about:blank is true, then run the iframe load event steps given targetNavigable's container.

    2. Return.

    In this case, some JavaScript code was executed, but no new Document was created, so we will not perform a navigation.

  8. Assert: initiatorOrigin is newDocument's origin.

  9. Let entryToReplace be targetNavigable's active session history entry.

  10. Let oldDocState be entryToReplace's document state.

  11. Let documentState be a new document state with

    document
    newDocument
    history policy container
    a clone of the oldDocState's history policy container if it is non-null; null otherwise
    request referrer
    oldDocState's request referrer
    request referrer policy
    oldDocState's request referrer policy or should this be the referrerPolicy that was passed to navigate?
    initiator origin
    initiatorOrigin
    origin
    initiatorOrigin
    about base URL
    oldDocState's about base URL
    resource
    null
    ever populated
    true
    navigable target name
    oldDocState's navigable target name

  12. Let historyEntry be a new session history entry, with

    URL
    entryToReplace's URL
    document state
    documentState

    For the URL, we do not use url, i.e. the actual javascript: URL that the navigate algorithm was called with. This means javascript: URLs are never stored in session history, and so can never be traversed to.

  13. Append session history traversal steps to targetNavigable's traversable to finalize a cross-document navigation with targetNavigable, historyHandling, userInvolvement, and historyEntry.

To evaluate a javascript: URL given a navigable targetNavigable, a URL url, an origin newDocumentOrigin, and a user navigation involvement userInvolvement:

  1. Let urlString be the result of running the URL serializer on url.

  2. Let encodedScriptSource be the result of removing the leading "javascript:" from urlString.

  3. Let scriptSource be the UTF-8 decoding of the percent-decoding of encodedScriptSource.

  4. Let settings be targetNavigable's active document's relevant settings object.

  5. Let baseURL be settings's API base URL.

  6. Let script be the result of creating a classic script given scriptSource, settings, baseURL, and the default script fetch options.

  7. Let evaluationStatus be the result of running the classic script script.

  8. Let result be null.

  9. If evaluationStatus is a normal completion, and evaluationStatus.[[Value]] is a String, then set result to evaluationStatus.[[Value]].

  10. Otherwise, return null.

  11. Let response be a new response with

    URL
    targetNavigable's active document's URL
    header list
    « (`Content-Type`, `text/html;charset=utf-8`) »
    body
    the UTF-8 encoding of result, as a body

    The encoding to UTF-8 means that unpaired surrogates will not roundtrip, once the HTML parser decodes the response body.

  12. Let policyContainer be targetNavigable's active document's policy container.

  13. Let finalSandboxFlags be policyContainer's CSP list's CSP-derived sandboxing flags.

  14. Let coop be targetNavigable's active document's opener policy.

  15. Let coopEnforcementResult be a new opener policy enforcement result with

    url
    url
    origin
    newDocumentOrigin
    opener policy
    coop

  16. Let navigationParams be a new navigation params, with

    id
    navigationId
    navigable
    targetNavigable
    request
    null this will cause the referrer of the resulting Document to be null; is that correct?
    response
    response
    fetch controller
    null
    commit early hints
    null
    COOP enforcement result
    coopEnforcementResult
    reserved environment
    null
    origin
    newDocumentOrigin
    policy container
    policyContainer
    final sandboxing flag set
    finalSandboxFlags
    opener policy
    coop
    navigation timing type
    "navigate"
    about base URL
    targetNavigable's active document's about base URL
    user involvement
    userInvolvement

  17. Return the result of loading an HTML document given navigationParams.

7.4.2.3.3 Fragment navigations

To navigate to a fragment given a navigable navigable, a URL url, a history handling behavior historyHandling, a user navigation involvement userInvolvement, an Element-or-null sourceElement, a serialized state-or-null navigationAPIState, and a navigation ID navigationId:

  1. Let navigation be navigable's active window's navigation API.

  2. Let destinationNavigationAPIState be navigable's active session history entry's navigation API state.

  3. If navigationAPIState is not null, then set destinationNavigationAPIState to navigationAPIState.

  4. Let continue be the result of firing a push/replace/reload navigate event at navigation with navigationType set to historyHandling, isSameDocument set to true, userInvolvement set to userInvolvement, sourceElement set to sourceElement, destinationURL set to url, and navigationAPIState set to destinationNavigationAPIState.

  5. If continue is false, then return.

  6. Let historyEntry be a new session history entry, with

    URL
    url
    document state
    navigable's active session history entry's document state
    navigation API state
    destinationNavigationAPIState
    scroll restoration mode
    navigable's active session history entry's scroll restoration mode

    For navigations performed with navigation.navigate(), the value provided by the state option is used for the new navigation API state. (This will set it to the serialization of undefined, if no value is provided for that option.) For other fragment navigations, including user-initiated ones, the navigation API state is carried over from the previous entry.

    The classic history API state is never carried over.

  7. Let entryToReplace be navigable's active session history entry if historyHandling is "replace", otherwise null.

  8. Let history be navigable's active document's history object.

  9. Let scriptHistoryIndex be history's index.

  10. Let scriptHistoryLength be history's length.

  11. If historyHandling is "push", then:

    1. Set history's state to null.

    2. Increment scriptHistoryIndex.

    3. Set scriptHistoryLength to scriptHistoryIndex + 1.

  12. Set navigable's active document's URL to url.

  13. Set navigable's active session history entry to historyEntry.

  14. Update document for history step application given navigable's active document, historyEntry, true, scriptHistoryIndex, scriptHistoryLength, and historyHandling.

    This algorithm will be called twice as a result of a single fragment navigation: once synchronously, where best-guess values scriptHistoryIndex and scriptHistoryLength are set, history.state is nulled out, and various events are fired; and once asynchronously, where the final values for index and length are set, history.state remains untouched, and no events are fired.

  15. Scroll to the fragment given navigable's active document.

    If the scrolling fails because the Document is new and the relevant ID has not yet been parsed, then the second asynchronous call to update document for history step application will take care of scrolling.

  16. Let traversable be navigable's traversable navigable.

  17. Append the following session history synchronous navigation steps involving navigable to traversable:

    1. Finalize a same-document navigation given traversable, navigable, historyEntry, entryToReplace, historyHandling, and userInvolvement.

    2. Invoke WebDriver BiDi fragment navigated with navigable and a new WebDriver BiDi navigation status whose id is navigationId, url is url, and status is "complete".

To finalize a same-document navigation given a traversable navigable traversable, a navigable targetNavigable, a session history entry targetEntry, a session history entry-or-null entryToReplace, a history handling behavior historyHandling, and a user navigation involvement userInvolvement:

This is used by both fragment navigations and by the URL and history update steps, which are the only synchronous updates to session history. By virtue of being synchronous, those algorithms are performed outside of the top-level traversable's session history traversal queue. This puts them out of sync with the top-level traversable's current session history step, so this algorithm is used to resolve conflicts due to race conditions.

  1. Assert: this is running on traversable's session history traversal queue.

  2. If targetNavigable's active session history entry is not targetEntry, then return.

  3. Let targetStep be null.

  4. Let targetEntries be the result of getting session history entries for targetNavigable.

  5. If entryToReplace is null, then:

    1. Clear the forward session history of traversable.

    2. Set targetStep to traversable's current session history step + 1.

    3. Set targetEntry's step to targetStep.

    4. Append targetEntry to targetEntries.

    Otherwise:

    1. Replace entryToReplace with targetEntry in targetEntries.

    2. Set targetEntry's step to entryToReplace's step.

    3. Set targetStep to traversable's current session history step.

  6. Apply the push/replace history step targetStep to traversable given historyHandling and userInvolvement.

    This is done even for "replace" navigations, as it resolves race conditions across multiple synchronous navigations.

7.4.2.3.4 Non-fetch schemes and external software

The input to attempt to create a non-fetch scheme document is the non-fetch scheme navigation params struct. It is a lightweight version of navigation params which only carries parameters relevant to the non-fetch scheme navigation case. It has the following items:

id
null or a navigation ID
navigable
the navigable experiencing the navigation
URL
a URL
target snapshot sandboxing flags
the target snapshot params's sandboxing flags present during navigation
source snapshot has transient activation
a copy of the source snapshot params's has transient activation boolean present during activation
initiator origin

an origin possibly for use in a user-facing prompt to confirm the invocation of an external software package

This differs slightly from a document state's initiator origin in that a non-fetch scheme navigation params's initiator origin follows redirects up to the last fetch scheme URL in a redirect chain that ends in a non-fetch scheme URL.

navigation timing type
a NavigationTimingType used for creating the navigation timing entry for the new Document (if one is created)
user involvement
a user navigation involvement used when obtaining a browsing context for the new Document (if one is created)

To attempt to create a non-fetch scheme document, given a non-fetch scheme navigation params navigationParams:

  1. Let url be navigationParams's URL.
  2. Let navigable be navigationParams's navigable.

  3. If url is to be handled using a mechanism that does not affect navigable, e.g., because url's scheme is handled externally, then:

    1. Hand-off to external software given url, navigable, navigationParams's target snapshot sandboxing flags, navigationParams's source snapshot has transient activation, and navigationParams's initiator origin.

    2. Return null.

  4. Handle url by displaying some sort of inline content, e.g., an error message because the specified scheme is not one of the supported protocols, or an inline prompt to allow the user to select a registered handler for the given scheme. Return the result of displaying the inline content given navigable, navigationParams's id, navigationParams's navigation timing type, and navigationParams's user involvement.

    In the case of a registered handler being used, navigate will be invoked with a new URL.

To hand-off to external software given a URL or response resource, a navigable navigable, a sandboxing flag set sandboxFlags, a boolean hasTransientActivation, and an origin initiatorOrigin, user agents should:

  1. If all of the following are true:

    then return without invoking the external software package.

    Navigation inside an iframe toward external software can be seen by users as a new popup or a new top-level navigation. That's why its is allowed in sandboxed iframe only when one of allow-popups, allow-top-navigation, allow-top-navigation-by-user-activation, or allow-top-navigation-to-custom-protocols is specified.

  2. Perform the appropriate handoff of resource while attempting to mitigate the risk that this is an attempt to exploit the target software. For example, user agents could prompt the user to confirm that initiatorOrigin is to be allowed to invoke the external software in question. In particular, if hasTransientActivation is false, then the user agent should not invoke the external software package without prior user confirmation.

    For example, there could be a vulnerability in the target software's URL handler which a hostile page would attempt to exploit by tricking a user into clicking a link.

7.4.2.4 Preventing navigation

A couple of scenarios can intervene early in the navigation process and put the whole thing to a halt. This can be especially exciting when multiple navigables are navigating at the same time, due to a session history traversal.

A navigable source is allowed by sandboxing to navigate a second navigable target, given a source snapshot params sourceSnapshotParams, if the following steps return true:

  1. If source is target, then return true.

  2. If source is an ancestor of target, then return true.

  3. If target is an ancestor of source, then:

    1. If target is not a top-level traversable, then return true.

    2. If sourceSnapshotParams's has transient activation is true, and sourceSnapshotParams's sandboxing flags's sandboxed top-level navigation with user activation browsing context flag is set, then return false.

    3. If sourceSnapshotParams's has transient activation is false, and sourceSnapshotParams's sandboxing flags's sandboxed top-level navigation without user activation browsing context flag is set, then return false.

    4. Return true.

  4. If target is a top-level traversable:

    1. If source is the one permitted sandboxed navigator of target, then return true.

    2. If sourceSnapshotParams's sandboxing flags's sandboxed navigation browsing context flag is set, then return false.

    3. Return true.

  5. If sourceSnapshotParams's sandboxing flags's sandboxed navigation browsing context flag is set, then return false.

  6. Return true.

To check if unloading is canceled for a list of navigables navigablesThatNeedBeforeUnload, given an optional traversable navigable traversable, an optional integer targetStep, and an optional user navigation involvement userInvolvementForNavigateEvent, run these steps. They return "canceled-by-beforeunload", "canceled-by-navigate", or "continue".

  1. Let documentsToFireBeforeunload be the active document of each item in navigablesThatNeedBeforeUnload.

  2. Let unloadPromptShown be false.

  3. Let finalStatus be "continue".

  4. If traversable was given, then:

    1. Assert: targetStep and userInvolvementForNavigateEvent were given.

    2. Let targetEntry be the result of getting the target history entry given traversable and targetStep.

    3. If targetEntry is not traversable's current session history entry, and targetEntry's document state's origin is the same as traversable's current session history entry's document state's origin, then:

      In this case, we're going to fire the navigate event for traversable here. Because under some circumstances it might be canceled, we need to do this separately from other traversal navigate events, which happen later.

      Additionally, because we want beforeunload events to fire before navigate events, this means we need to fire beforeunload for traversable here (if applicable), instead of doing it as part of the below loop over documentsToFireBeforeunload.

      1. Let eventsFired be false.

      2. Let needsBeforeunload be true if navigablesThatNeedBeforeUnload contains traversable; otherwise false.

      3. If needsBeforeunload is true, then remove traversable's active document from documentsToFireBeforeunload.

      4. Queue a global task on the navigation and traversal task source given traversable's active window to perform the following steps:

        1. If needsBeforeunload is true, then:

          1. Let (unloadPromptShownForThisDocument, unloadPromptCanceledByThisDocument) be the result of running the steps to fire beforeunload given traversable's active document and false.

          2. If unloadPromptShownForThisDocument is true, then set unloadPromptShown to true.

          3. If unloadPromptCanceledByThisDocument is true, then set finalStatus to "canceled-by-beforeunload".

        2. If finalStatus is "canceled-by-beforeunload", then abort these steps.

        3. Let navigation be traversable's active window's navigation API.

        4. Let navigateEventResult be the result of firing a traverse navigate event at navigation given targetEntry and userInvolvementForNavigateEvent.

        5. If navigateEventResult is false, then set finalStatus to "canceled-by-navigate".

        6. Set eventsFired to true.

      5. Wait until eventsFired is true.

      6. If finalStatus is not "continue", then return finalStatus.

  5. Let totalTasks be the size of documentsToFireBeforeunload.

  6. Let completedTasks be 0.

  7. For each document of documentsToFireBeforeunload, queue a global task on the navigation and traversal task source given document's relevant global object to run the steps:

    1. Let (unloadPromptShownForThisDocument, unloadPromptCanceledByThisDocument) be the result of running the steps to fire beforeunload given document and unloadPromptShown.

    2. If unloadPromptShownForThisDocument is true, then set unloadPromptShown to true.

    3. If unloadPromptCanceledByThisDocument is true, then set finalStatus to "canceled-by-beforeunload".

    4. Increment completedTasks.

  8. Wait for completedTasks to be totalTasks.

  9. Return finalStatus.

The steps to fire beforeunload given a Document document and a boolean unloadPromptShown are:

  1. Let unloadPromptCanceled be false.

  2. Increase the document's unload counter by 1.

  3. Increase document's relevant agent's event loop's termination nesting level by 1.

  4. Let eventFiringResult be the result of firing an event named beforeunload at document's relevant global object, using BeforeUnloadEvent, with the cancelable attribute initialized to true.

  5. Decrease document's relevant agent's event loop's termination nesting level by 1.

  6. If all of the following are true:

    then:

    1. Set unloadPromptShown to true.

    2. Let userPromptHandler be the result of WebDriver BiDi user prompt opened with document's relevant global object, "beforeunload", and "".

    3. If userPromptHandler is "dismiss", then set unloadPromptCanceled to true.

    4. If userPromptHandler is "none", then:

      1. Ask the user to confirm that they wish to unload the document, and pause while waiting for the user's response.

        The message shown to the user is not customizable, but instead determined by the user agent. In particular, the actual value of the returnValue attribute is ignored.

      2. If the user did not confirm the page navigation, then set unloadPromptCanceled to true.

    5. Invoke WebDriver BiDi user prompt closed with document's relevant global object, "beforeunload", and true if unloadPromptCanceled is false or false otherwise.

  7. Decrease document's unload counter by 1.

  8. Return (unloadPromptShown, unloadPromptCanceled).

7.4.2.5 Aborting navigation

Each navigable has an ongoing navigation, which is a navigation ID, "traversal", or null, initially null. It is used to track navigation aborting and to prevent any navigations from taking place during traversal.

To set the ongoing navigation for a navigable navigable to newValue:

  1. If navigable's ongoing navigation is equal to newValue, then return.

  2. Inform the navigation API about aborting navigation given navigable.

  3. Set navigable's ongoing navigation to newValue.

7.4.3 Reloading and traversing

To reload a navigable navigable given an optional serialized state-or-null navigationAPIState (default null) and an optional user navigation involvement userInvolvement (default "none"):

  1. If userInvolvement is not "browser UI", then:

    1. Let navigation be navigable's active window's navigation API.

    2. Let destinationNavigationAPIState be navigable's active session history entry's navigation API state.

    3. If navigationAPIState is not null, then set destinationNavigationAPIState to navigationAPIState.

    4. Let continue be the result of firing a push/replace/reload navigate event at navigation with navigationType set to "reload", isSameDocument set to false, userInvolvement set to userInvolvement, destinationURL set to navigable's active session history entry's URL, and navigationAPIState set to destinationNavigationAPIState.

    5. If continue is false, then return.

  2. Set navigable's active session history entry's document state's reload pending to true.

  3. Let traversable be navigable's traversable navigable.

  4. Append the following session history traversal steps to traversable:

    1. Apply the reload history step to traversable given userInvolvement.

To traverse the history by a delta given a traversable navigable traversable, an integer delta, and an optional Document sourceDocument:

  1. Let sourceSnapshotParams and initiatorToCheck be null.

  2. Let userInvolvement be "browser UI".

  3. If sourceDocument is given, then:

    1. Set sourceSnapshotParams to the result of snapshotting source snapshot params given sourceDocument.

    2. Set initiatorToCheck to sourceDocument's node navigable.

    3. Set userInvolvement to "none".

  4. Append the following session history traversal steps to traversable:

    1. Let allSteps be the result of getting all used history steps for traversable.

    2. Let currentStepIndex be the index of traversable's current session history step within allSteps.

    3. Let targetStepIndex be currentStepIndex plus delta.

    4. If allSteps[targetStepIndex] does not exist, then abort these steps.

    5. Apply the traverse history step allSteps[targetStepIndex] to traversable, given sourceSnapshotParams, initiatorToCheck, and userInvolvement.

Apart from the navigate algorithm, session history entries can be pushed or replaced via one more mechanism, the URL and history update steps. The most well-known callers of these steps are the history.replaceState() and history.pushState() APIs, but various other parts of the standard also need to perform updates to the active history entry, and they use these steps to do so.

The URL and history update steps, given a Document document, a URL newURL, an optional serialized state-or-null serializedData (default null), and an optional history handling behavior historyHandling (default "replace"), are:

  1. Let navigable be document's node navigable.

  2. Let activeEntry be navigable's active session history entry.

  3. Let newEntry be a new session history entry, with

    URL
    newURL
    serialized state
    if serializedData is not null, serializedData; otherwise activeEntry's classic history API state
    document state
    activeEntry's document state
    scroll restoration mode
    activeEntry's scroll restoration mode
    persisted user state
    activeEntry's persisted user state

  4. If document's is initial about:blank is true, then set historyHandling to "replace".

    This means that pushState() on an initial about:blank Document behaves as a replaceState() call.

  5. Let entryToReplace be activeEntry if historyHandling is "replace", otherwise null.

  6. If historyHandling is "push", then:

    1. Increment document's history object's index.

    2. Set document's history object's length to its index + 1.

    These are temporary best-guess values for immediate synchronous access.

  7. If serializedData is not null, then restore the history object state given document and newEntry.

  8. Set the URL given document to newURL.

    Since this is neither a navigation nor a history traversal, it does not cause a hashchange event to be fired.

  9. Set document's latest entry to newEntry.

  10. Set navigable's active session history entry to newEntry.

  11. Update the navigation API entries for a same-document navigation given document's relevant global object's navigation API, newEntry, and historyHandling.

  12. Let traversable be navigable's traversable navigable.

  13. Append the following session history synchronous navigation steps involving navigable to traversable:

    1. Finalize a same-document navigation given traversable, navigable, newEntry, entryToReplace, historyHandling, and "none".

    2. Invoke WebDriver BiDi history updated with navigable.

Although both fragment navigation and the URL and history update steps perform synchronous history updates, only fragment navigation contains a synchronous call to update document for history step application. The URL and history update steps instead perform a few select updates inside the above algorithm, omitting others. This is somewhat of an unfortunate historical accident, and generally leads to web-developer sadness about the inconsistency. For example, this means that popstate events fire for fragment navigations, but not for history.pushState() calls.

7.4.5 Populating a session history entry

As explained in the overview, both navigation and traversal involve creating a session history entry and then attempting to populate its document member, so that it can be presented inside the navigable.

This involves either: using an already-given response; using the srcdoc resource stored in the session history entry; or fetching. The process has several failure modes, which can either result in doing nothing (leaving the navigable on its currently-active Document) or can result in populating the session history entry with an error document.

To attempt to populate the history entry's document for a session history entry entry, given a navigable navigable, a NavigationTimingType navTimingType, a source snapshot params sourceSnapshotParams, a target snapshot params targetSnapshotParams, a user navigation involvement userInvolvement, an optional navigation ID-or-null navigationId (default null), an optional navigation params-or-null navigationParams (default null), an optional string cspNavigationType (default "other"), an optional boolean allowPOST (default false), and optional algorithm steps completionSteps (default an empty algorithm):

  1. Assert: this is running in parallel.

  2. Assert: if navigationParams is non-null, then navigationParams's response is non-null.

  3. Let documentResource be entry's document state's resource.

  4. If navigationParams is null, then:

    1. If documentResource is a string, then set navigationParams to the result of creating navigation params from a srcdoc resource given entry, navigable, targetSnapshotParams, userInvolvement, navigationId, and navTimingType.

    2. Otherwise, if all of the following are true:

      then set navigationParams to the result of creating navigation params by fetching given entry, navigable, sourceSnapshotParams, targetSnapshotParams, cspNavigationType, userInvolvement, navigationId, and navTimingType.

    3. Otherwise, if entry's URL's scheme is not a fetch scheme, then set navigationParams to a new non-fetch scheme navigation params, with

      id
      navigationId
      navigable
      navigable
      URL
      entry's URL
      target snapshot sandboxing flags
      targetSnapshotParams's sandboxing flags
      source snapshot has transient activation
      sourceSnapshotParams's has transient activation
      initiator origin
      entry's document state's initiator origin
      navigation timing type
      navTimingType
      user involvement
      userInvolvement

  5. Queue a global task on the navigation and traversal task source, given navigable's active window, to run these steps:

    1. If navigable's ongoing navigation no longer equals navigationId, then run completionSteps and abort these steps.

    2. Let saveExtraDocumentState be true.

      Usually, in the cases where we end up populating entry's document state's document, we then want to save some of the state from that Document into entry. This ensures that if there are future traversals to entry where its document has been destroyed, we can use that state when creating a new Document.

      However, in some specific cases, saving the state would be unhelpful. For those, we set saveExtraDocumentState to false later in this algorithm.

    3. If navigationParams is a non-fetch scheme navigation params, then:

      1. Set entry's document state's document to the result of running attempt to create a non-fetch scheme document given navigationParams.

        This can result in setting entry's document state's document to null, e.g., when handing-off to external software.

      2. Set saveExtraDocumentState to false.

    4. Otherwise, if any of the following are true:

      then:

      1. Set entry's document state's document to the result of creating a document for inline content that doesn't have a DOM, given navigable, null, navTimingType, and userInvolvement. The inline content should indicate to the user the sort of error that occurred.

      2. Make document unsalvageable given entry's document state's document and "navigation-failure".

      3. Set saveExtraDocumentState to false.

      4. If navigationParams is not null, then:

        1. Run the environment discarding steps for navigationParams's reserved environment.

        2. Invoke WebDriver BiDi navigation failed with navigable and a new WebDriver BiDi navigation status whose id is navigationId, status is "canceled", and url is navigationParams's response's URL.