blob: faec12d104f6b3d8abd7ff818171f8cb47d404fa [file] [log] [blame] [view]
Charlie Reisb33534992020-06-26 05:28:171# Navigation Concepts
2
3This documentation covers a set of important topics to understand related to
4navigation. For a timeline of how a given navigation proceeds, see [Life of a
5Navigation](navigation.md).
6
7[TOC]
8
9
10## Same-Document and Cross-Document Navigations
11
12Chromium defines two types of navigations based on whether the navigation
13results in a new document or not. A _cross-document_ navigation is one that
14results in creating a new document to replace an existing document. This is
15the type of navigation that most users are familiar with. A _same-document_
16navigation does not create a new document, but rather keeps the same document
17and changes state associated with it. A same-document navigation does create a
18new session history entry, even though the same document remains active. This
19can be the result of one of the following cases:
20
21* Navigating to a fragment within an existing document (e.g.
22 `https://foo.com/1.html#fragment`).
23* A document calling the `history.pushState()` or `history.replaceState()` APIs.
24* A session history navigation that stays in the same document, such as going
25 back/forward to an existing entry for the same document.
26
27
28## Browser-Initiated and Renderer-Initiated Navigations
29
30Chromium also defines two types of navigations based on which process started
31the navigation: _browser-initiated_ and _renderer-initiated_. This distinction
32is useful when making decisions about navigations, for example whether an
33ongoing navigation needs to be cancelled or not when a new navigation is
34starting. It is also used for some security decisions, such as whether to
35display the target URL of the navigation in the address bar or not.
36Browser-initiated navigations are more trustworthy, as they are usually in
37response to a user interaction with the UI of the browser. Renderer-initiated
38navigations originate in the renderer process, which may be under the control of
39an attacker. Note that some renderer-initiated navigations may be considered
40user-initiated, if they were performed with a [user
41activation](https://mustaqahmed.github.io/user-activation-v2/) (e.g., links),
42while others are not user-initiated (e.g., script navigations).
43
44
45## Last Committed, Pending, and Visible URLs
46
47Many features care about the URL or Origin of a given document, or about a
48pending navigation, or about what is showing in the address bar. These are all
49different concepts with different security implications, so be sure to use the
50correct value for your use case.
51
52See [Origin vs URL](security/origin-vs-url.md) when deciding whether to check
53the Origin or URL. In many cases that care about the security context, Origin
54should be preferred.
55
56The _last committed_ URL or Origin represents the document that is currently in
57the frame, regardless of what is showing in the address bar. This is almost
58always what should be used for feature-related state, unless a feature is
59explicitly tied to the address bar (e.g., padlock icon). See
60`RenderFrameHost::GetLastCommittedOrigin` (or URL) and
61`NavigationController::GetLastCommittedEntry`.
62
63The _pending_ URL exists when a main frame navigation has started but has not
64yet committed. This URL is only sometimes shown to the user in the address bar;
65see the description of visible URLs below. Features should rarely need to care
66about the pending URL, unless they are probing for a navigation they expect to
67have started. See `NavigationController::GetPendingEntry`.
68
69The _visible_ URL is what the address bar displays. This is carefully managed to
70show the main frame's last committed URL in most cases, and the pending URL in
71cases where it is safe and unlikely to be abused for a _URL spoof attack_ (where
72an attacker is able to display content as if it came from a victim URL). In
73general, the visible URL is:
74
75 * The pending URL for browser-initiated navigations like typed URLs or
76 bookmarks, excluding session history navigations.
77 * The last committed URL for renderer-initiated navigations, where an attacker
78 might have control over the contents of the document and the pending URL.
79 * A renderer-initiated navigation's URL is only visible while pending if it
80 opens in a new unmodified tab (so that an unhelpful `about:blank` URL is not
81 displayed), but only until another document tries to access the initial empty
82 document of the new tab. For example, an attacker window might open a new tab
83 to a slow victim URL, then inject content into the initial `about:blank`
84 document as if the slow URL had committed. If that occurs, the visible URL
85 reverts to `about:blank` to avoid a URL spoof scenario. Once the initial
86 navigation commits in the new tab, pending renderer-initiated navigation URLs
87 are no longer displayed.
88
89
90## Virtual URLs
91
92Virtual URLs are a way for features to change how certain URLs are displayed to
93the user (whether visible or committed). They are generally implemented using
94BrowserURLHandlers. Examples include:
95
96 * View Source URLs, where the `view-source:` prefix is not present in the
97 actual committed URL.
98 * DOM Distiller URLs, where the original URL is displayed to the user rather
99 than the more complex distiller URL.
100
101
102## Redirects
103
104Navigations can redirect to other URLs in two different ways.
105
106A _server redirect_ happens when the browser receives a 300-level HTTP response
107code before the document commits, telling it to request a different URL,
108possibly cross-origin. The new request will usually be an HTTP GET request,
109unless the redirect is triggered by a 307 or 308 response code, which preserves
110the original request method and body. Server redirects are managed by a single
111NavigationRequest. No document is committed to session history, but the original
112URL remains in the redirect chain.
113
114In contrast, a _client redirect_ happens after a document has committed, when
115the HTML in the document instructs the browser to request a new document (e.g.,
116via meta tags or JavaScript). Blink classifies the navigation as a client
117redirect based partly on how much time has passed. In this case, a session
118history item is created for the redirecting document, but it gets replaced when
119the actual destination document commits. A separate NavigationRequest is used
120for the second navigation.
121
122
123## Concurrent Navigations
124
125Many navigations can be in progress simultaneously. In general, every frame is
126considered independent and may have its own navigations(s), with each tracked by
127a NavigationRequest. Within a frame, it is possible to have multiple concurrent
128navigations:
129
130 * **A cross-document navigation waiting for its final response (at most one per
131 frame).** The NavigationRequest is owned by FrameTreeNode during this stage,
132 which can take several seconds. Some special case navigations do not use a
133 network request and skip this stage (e.g., `about:blank`, `about:srcdoc`,
134 MHTML).
135 * **A queue of cross-document navigations that are between "ready to commit"
136 and "commit," while the browser process waits for a commit acknowledgement
137 from the renderer process.** While rare, it is possible for multiple
138 navigations to be in this stage concurrently if the renderer process is slow.
139 The NavigationRequests are owned by the RenderFrameHost during this stage,
140 which is usually short-lived.
141 * **Same-document navigations.** These can be:
142 * Renderer-initiated (e.g., `pushState`, fragment link click). In this case,
143 the browser process creates and destroys a NavigationRequest in the same
144 task.
145 * Browser-initiated (e.g., omnibox fragment change). In this case, the
146 browser process creates a NavigationRequest owned by the RenderFrameHost
147 and immediately tells the renderer to commit.
148
149Note that the navigation code is not re-entrant. Callers must not start a new
150navigation while a call to `NavigateWithoutEntry` or
151`NavigateToExistingPendingEntry` is on the stack, to avoid a CHECK that guards
152against use-after-free for `pending_entry_`.
153
154
155## Rules for Canceling Navigations
156
157We generally do not want an abusive page to prevent the user from navigating
158away, such as by endlessly starting new navigations that interrupt or cancel the
159user's attempts. Generally, a new navigation will cancel an existing one in a
160frame, but we make the following exception: a renderer-initiated navigation is
161ignored iff there is an ongoing browser-initiated navigation and the new
162navigation lacks a user activation. (This is implemented in
163`Navigator::ShouldIgnoreIncomingRendererRequest`.)
164
165NavigationThrottles also have an ability to cancel navigations when desired by a
166feature. Keep in mind that it is problematic to simulate a redirect by canceling
167a navigation and starting a new one, since this may lose relevant context from
168the original navigation (e.g., ReloadType, CSP state, Sec-Fetch-Metadata state,
169redirect chain, etc), and it will lead to unexpected observer events and metrics
170(e.g., extra navigation starts, inflated numbers of canceled navigations, etc).
171Feature authors that want to simulate redirects may want to consider using a
172URLLoaderRequestInterceptor instead.
173
174
175## Error Pages
176
177There are several types of error pages that can be displayed when a navigation
178is not successful.
179
180The server can return a custom error page, such as a 400 or 500 level HTTP
181response code page. These pages are rendered much like a successful navigation
182to the site (and go into an appropriate process for that site), but the error
183code is available and `NavigationHandle::IsErrorPage()` is true.
184
185If the navigation fails to get a response from the server (e.g., the DNS lookup
186fails), then Chromium will display an error page. For main frames, this error
187page will be in a special error page process, not affiliated with any site or
188containing any untrustworthy content from the web. In these failed cases,
189NetErrorHelperCore may try to reload the URL at a later time (e.g., if a network
190connection comes back online), to load the document in an appropriate process.
191
192If instead the navigation is blocked (e.g., by an extension API or a
193NavigationThrottle), then Chromium will similarly display an error page in a
194special error page process. However, in blocked cases, Chromium will not attempt
195to reload the URL at a later time.
196
197
198## Interstitial Pages
199
200Interstitial pages are implemented as committed error pages. (Prior to
201[issue 448486](https://crbug.com/448486), they were implemented as overlays.)
202The original in-progress navigation is canceled when the interstitial is
203displayed, and Chromium repeats the navigation if the user chooses to proceed.
204
205Note that some interstitials can be shown after a page has committed (e.g., when
206a subresource load triggers a Safe Browsing error). In this case, Chromium
207navigates away from the original page to the interstitial page, with the intent
208of replacing the original NavigationEntry. However, the original NavigationEntry
209is preserved in `NavigationControllerImpl::entry_replaced_by_post_commit_error_`
210in case the user chooses to dismiss the interstitial and return to the original
211page.