WEB / WEB-10.01

Browser processes and navigation

Read browser UI, network loading and renderer document state through ownership boundaries.

CORE · RED · BLUE · ARTIFACT · PRACTICE

Read every scenario without motion

HTML commit

Document A active
Document A is active; navigation to B has not committed. Network metadata arriving at the browser, commit arriving at the renderer and confirmation returning to the browser change distinct states. Active A is not a pixel measurement here.
Browser UI
Active: A
Network service
Response B: absent
Renderer
Document A
Navigation intent
The browser selects an ordinary HTML navigation candidate while the old document remains active.
Browser UI
Intent: B; active A
Network service
Response B: pending
Renderer
Document A
Response prepared locally
Selected response metadata and stream become ready in the Network service; no DNS/TLS/HTTP exchange is claimed.
Browser UI
Intent B; active A
Network service
HTML metadata + stream ready
Renderer
Document A
HTML response ready
Network service metadata reaches the browser; the renderer has not received a new document.
Browser UI
Intent B; response ready
Network service
HTML headers/body available
Renderer
Document A
Renderer selected
Renderer B is selected in this profile; selection does not commit its new document.
Browser UI
Renderer B selected
Network service
HTML stream available
Renderer
B ready; document absent
Commit delivered
Commit and stream handoff reach the renderer; Document B now enters loading.
Browser UI
Confirmation pending; active A
Network service
Stream handoff complete
Renderer
Document B: loading
Confirmation received
Renderer confirmation reaches the browser; the active-document and URL record becomes B.
Browser UI
Active: B; URL B
Network service
Response B consumed
Renderer
Document B: loading
Rendering remains separate
Parsing may continue; first-pixel presentation and load timing are not measured by this model.
Browser UI
Active: B
Network service
No fresh request implied
Renderer
DOM work available; pixels unmeasured

Fragment · same DOM

Document A active
Document A and its summary target already exist; there is no network work in this fixture.
Browser UI
Active: A
Network service
Not required
Renderer
Document A: summary exists
Fragment chosen
The summary fragment in the existing document is selected and Document A identity is retained.
Browser UI
Intent: A#summary
Network service
Not required
Renderer
Document A unchanged
History updated
Same-document URL/history changes without creating a new HTML response or document commit.
Browser UI
URL: A#summary; active A
Network service
Not required
Renderer
Document A unchanged
Existing target used
The existing summary target is applied; DOM nodes are not created from another response.
Browser UI
URL: A#summary
Network service
Not required
Renderer
Same Document A; target summary

File · no new DOM

Document A active
The old document remains active; the download fixture response has not yet been selected.
Browser UI
Active: A
Network service
File response pending
Renderer
Document A
File intent
The browser handles a file response candidate without assuming HTML for the renderer.
Browser UI
Intent: file; active A
Network service
Attachment profile
Renderer
Document A
File metadata ready
The Network service holds selected file metadata ready; the browser has not yet made its download decision.
Browser UI
Intent file; active A
Network service
File metadata + bytes ready
Renderer
Document A
File response delivered
Selected attachment response metadata arrives without committing a new document.
Browser UI
Attachment ready; active A
Network service
File bytes available
Renderer
Document A
Download branch selected
The response goes to file handling; there is no new HTML document in Renderer B.
Browser UI
Download selected; active A
Network service
File handing off
Renderer
No Document B
Boundary retained
Download selection is distinct from rendering success and retains the old document identity.
Browser UI
Active: A
Network service
No HTML commit
Renderer
Document A retained

ACTORS · STATE · DATA FLOW

A browser is an application environment

An address bar, document and network socket are distinct components. A browser turns received bytes into documents under web-platform rules, executes scripts, manages storage and permissions, and presents frames. A server returning 200 is one dependency in that journey. Response handling, document creation, code and resource processing, and a usable view have separate outcomes.

Consider a book catalogue. An address bar showing /catalog records an accepted address. An Atlas heading in the DOM records a document observation. A visible Atlas heading records a presentation observation. The lesson keeps these observations separate, so browser UI, renderer work and network service do not disappear inside a single green loaded box.

Separate processes and threads

A process is an operating-system execution and resource boundary; threads provide execution flows within it. Chromium divides browser UI and renderer work across processes. A renderer can have a main thread, compositor and helper work, while network and GPU/Viz services have implementation-specific placement. Work done by one application need not share one JavaScript call stack.

This distinction helps interpret a common failure: browser tab controls may remain responsive while a document main thread is busy, because browser UI and document script are different jobs. The actor cards supply no PID, memory or CPU measurements. They identify responsibility; determining actual process counts requires an observation of the particular browser version.

Tab count is not process count

One tab, one renderer is a memorable starting picture rather than a reliable architectural rule. Chromium considers document and worker coexistence, security principals, browsing context groups and platform resources. A cross-site iframe inside one tab can use another renderer, while related same-site documents may share a process. Site and origin isolation details also differ across platforms.

Two visible tabs therefore do not establish two independent application security boundaries. Process separation can strengthen browser defenses, but the catalogue API still decides who may receive a record. Renderer A and Renderer B are instructional aliases here. They do not claim that every navigation must start a new operating-system process.

Navigation intent, response and commit

A cross-document navigation starts with a URL candidate. The browser handles loading decisions, obtains a response when required and selects a suitable document target. Redirects can change the final destination, and cache or service workers mean that every navigation need not perform fresh DNS and TLS. The scene selects a Chromium-style coordination profile after an ordinary HTML response is available.

Commit delivery begins loading in the receiving renderer, and confirmation advances browser UI/history state. No IPC bytes are captured or invented here. A transfer represents completed message delivery. The browser card retains Document A until confirmation arrives, so the ownership boundary remains visible instead of announcing Document B before its receiver has acknowledged it.

A URL can change within the same document

A #summary link in the catalogue can navigate within the existing document. Document identity is retained while URL/history and the scroll target may change; another HTML response is not required. History API URL/history updates can also retain the document, although their observable event behavior is not identical to fragment navigation. This fixture selects an existing #summary fragment target.

An address observer and a document-identity observer can therefore see different kinds of change. A SPA route name changing does not automatically renew a session or server permission. The artifact retains activeDocument=A for its same-document row. networkFetchRequired=false describes this selected fragment operation, rather than every kind of navigation.

Commit, readiness and pixels are separate gates

Document.readyState distinguishes loading, interactive and complete lifecycle states. DOMContentLoaded normally follows parsing and deferred/module script work, rather than waiting for every image or async script. load covers a broader resource-loading boundary, while lazy resources and later fetches may remain outside it. Neither event records the exact instant of the first visible pixel.

The download branch handles a file response without committing a new HTML document to Renderer B. The normal branch also ends with DOM work available and pixels unmeasured. Playing the transfers makes byte delivery and frame presentation depend on different conditions, helping a learner avoid treating every blank view as an automatic server failure.

Read every scenario without motion

Commit scope

The initial document was separated from the new response
InitialDocument is A; the ordinary HTML response selects newDocument B. Response-ready alone does not establish a changed current document. Response, selected renderer and commit are different milestones.
Navigation ledger
Document A / HTML response B ready
Lifecycle boundary
Lifecycle gate pending
Presentation/authority
Outcome unknown
Commit ownership was tied to renderer knowledge
normalEvents places commit-delivered after renderer-selected. In this selected Chromium-style coordination, renderer B knows the new document. The alias is neither a process-allocation guarantee nor an actual IPC-wire record.
Navigation ledger
Document A / HTML response B ready
Lifecycle boundary
Commit delivered / renderer knows B
Presentation/authority
Outcome unknown
First-pixel results were not inferred from commit
pixelsMeasured is false. Renderer knowledge of document B does not measure first pixels. Presentation, lifecycle receipt and application-data permission are different questions.
Navigation ledger
Document A / HTML response B ready
Lifecycle boundary
Commit delivered / renderer knows B
Presentation/authority
Document B known / pixels unmeasured
Confirmation was read as a separate acknowledgement
The normal record supplies confirmationReceived true and ends with confirmation-received. Browser UI/state updates are explained after this selected acknowledgement. Sending commit does not establish receipt of confirmation.
Navigation ledger
Confirmation received after commit
Lifecycle boundary
Commit delivered / renderer knows B
Presentation/authority
Document B known / pixels unmeasured
A process label was not resource authority
A/B document aliases and process/sandbox boundaries do not become tenant/action decisions. Sharing a process grants no authority; separate processes do not establish API-data confidentiality.
Navigation ledger
Confirmation received after commit
Lifecycle boundary
Lifecycle ownership ≠ resource permission
Presentation/authority
Document B known / pixels unmeasured
The outcome retained the smallest observed milestones
The ledger supplies ordinary commit and confirmation while actualNetworkExecuted and pixelsMeasured remain false. It supports “Document B selected and confirmation received,” without adding network, pixel or server-authorization success.
Navigation ledger
Confirmation received after commit
Lifecycle boundary
Lifecycle ownership ≠ resource permission
Presentation/authority
Commit/confirmation supplied / pixels-authz unmeasured

Download branch

Response kind was separated from new-document creation
The download case has responseKind selected-attachment and downloadSelected true, with newDocument null and retainedDocument A. Successful download selection is not the branch that creates a new HTML document.
Navigation ledger
Attachment selected / document A retained
Lifecycle boundary
Lifecycle gate pending
Presentation/authority
Outcome unknown
The wrong inspected-object assumption was stopped
Inspecting a new document B would be incorrect because this branch retains A. Response status/type, document identity and selected download are separate records. Expecting a new DOM after download selection misreads lifecycle.
Navigation ledger
Attachment selected / document A retained
Lifecycle boundary
No new document / inspect retained A separately
Presentation/authority
Outcome unknown
Download selection was not a file-safety verdict
Selected attachment does not establish safe bytes or user authorization. The fixture performs no download transfer, file write or content analysis. Response-branch selection remains separate from application policy.
Navigation ledger
Attachment selected / document A retained
Lifecycle boundary
No new document / inspect retained A separately
Presentation/authority
Download selected / transfer-content safety unmeasured
Same-document navigation provided an ordinary negative comparison
The same-document case selects fragment summary with newDocument null and networkFetchRequired false. A is retained, but this is not a download branch. Equal null newDocument values do not imply the same mechanism.
Navigation ledger
Same-document fragment summary / no new fetch required
Lifecycle boundary
No new document / inspect retained A separately
Presentation/authority
Download selected / transfer-content safety unmeasured
Navigation type changed the corrective owner
HTML commit, same-document fragment and selected attachment require different work. Investigation identifies navigation kind first. A generic “load failed” label hides which stage was missing or unnecessary.
Navigation ledger
Same-document fragment summary / no new fetch required
Lifecycle boundary
HTML / fragment / attachment classified separately
Presentation/authority
Download selected / transfer-content safety unmeasured
Navigation explanations were not platform-wide claims
The selected profile does not generalize allocation or all browser/platform behavior. Both download and same-document cases have pixelsMeasured false. Their outcomes are not actual screenshots or sandbox verification.
Navigation ledger
Same-document fragment summary / no new fetch required
Lifecycle boundary
HTML / fragment / attachment classified separately
Presentation/authority
Branch known / platform and pixels unmeasured

ASSUMPTION · BOUNDARY · CONTROL

Ask who owns the signal

For an authorized review, split page opened into observations. Address bar and final URL, response status/Content-Type, document identity and rendered view come from different owners. Recording a final redirect destination does not erase earlier responses. A downloaded file also leaves no new HTML document to inspect in the selected branch.

Use the artifact to predict when Renderer B knows its new document, when browser UI receives confirmation, and what never changes in the same-document branch. These are mechanism-reading exercises with ordinary synthetic inputs. Process count or a screenshot alone does not establish approval to receive application data.

Separate navigation evidence from content decisions

A network record can describe an available response, DOM inspection can describe the current document, and a performance record can describe renderer work. These observations complement one another without individually proving the whole timeline. Record the version, navigation type and source path; a cache-served response is not a fresh wire capture.

Keep the scene aliases and selected-profile limits. A stalled UI does not establish a renderer sandbox bypass or server authorization failure here. Record the smallest supported event: commit confirmation has not arrived, Document A remains, or the file branch was selected. This keeps a finding tied to the mechanism actually observed.

Read every scenario without motion

Milestone review

Ordinary event order retained independent records
This artifact is a milestone ledger for the selected navigation model. response-ready, renderer-selected, commit-delivered and confirmation-received belong to distinct owners. Network-service preparation is not browser receipt; renderer commit knowledge is not browser confirmation. Fragment and download branches require no new HTML commit. normalEvents lists response-ready, renderer-selected, commit-delivered and confirmation-received. One request ID need not identify an entire document or user session. Correlation needs owner and navigation scope.
Lifecycle observations
Ready→selected→commit→confirmation
Owner/correlation review
Lifecycle gate pending
Evidence conclusion
Outcome unknown
Receiver knowledge was reviewed per milestone
The renderer knows the new document at commit delivery; the browser receives confirmation separately. The source supplies these completed facts. Cache receipt, response preparation and document commit are not reported as one event.
Lifecycle observations
Ready→selected→commit→confirmation
Owner/correlation review
Renderer knows B / browser receives confirmation later
Evidence conclusion
Outcome unknown
The benign same-document branch became a negative control
Fragment summary navigation retains A with newDocument null and networkFetchRequired false. An oracle requiring a new document would misclassify this ordinary branch. Branch kind is therefore part of the checks.
Lifecycle observations
Fragment: A retained / no new document required
Owner/correlation review
Renderer knows B / browser receives confirmation later
Evidence conclusion
Outcome unknown
Download outcomes were separated from document outcomes
Attachment selection yields newDocument null for a reason different from a same-document fragment. Outcome reasons explain different branches with equal null values. Browser presentation and file persistence need separate measurement.
Lifecycle observations
Fragment: A retained / no new document required
Owner/correlation review
Attachment: A retained / download selected
Evidence conclusion
Outcome unknown
Presentation coverage retained a separate verdict
All three cases have pixelsMeasured false. Lifecycle records can describe current document and navigation kind without proving first pixels or the complete rendered view. Missing observation does not prove an invisible page.
Lifecycle observations
Fragment: A retained / no new document required
Owner/correlation review
Attachment: A retained / download selected
Evidence conclusion
Lifecycle known / presentation UNKNOWN
Regression was chosen by expected work
Checks target B commit/confirmation for HTML, retention of A for a fragment and download selection for attachment. Actual IPC, process allocation and networks are not executed. New runtime outcomes need separate evidence.
Lifecycle observations
Fragment: A retained / no new document required
Owner/correlation review
Attachment: A retained / download selected
Evidence conclusion
Check branch-specific milestones, not one completion

Confirmation gap

The observation gap was separated from normal expectations
This artifact is a milestone ledger for the selected navigation model. response-ready, renderer-selected, commit-delivered and confirmation-received belong to distinct owners. Network-service preparation is not browser receipt; renderer commit knowledge is not browser confirmation. Fragment and download branches require no new HTML commit. The alternative review has a commit record but no observed confirmation receipt. The normal fixture supplies confirmationReceived true, which cannot replace the missing observation. Receiver knowledge is evaluated from its own record.
Lifecycle observations
Commit observed / confirmation unobserved
Owner/correlation review
Lifecycle gate pending
Evidence conclusion
Outcome unknown
A send record was not acknowledgement receipt
Sending commit does not prove confirmation reached the browser. Renderer-side and browser-side observations need separate coverage. This review does not measure actual message loss or timing causes.
Lifecycle observations
Commit observed / confirmation unobserved
Owner/correlation review
Commit send ≠ confirmation receipt
Evidence conclusion
Outcome unknown
No guessed conclusion was added about the old document
Missing confirmation does not prove that the current document is A; the renderer may know B. Distinct milestone owners prevent one missing record from rolling back every state.
Lifecycle observations
No rollback inference from one missing record
Owner/correlation review
Commit send ≠ confirmation receipt
Evidence conclusion
Outcome unknown
Pixel and policy evidence were not inferred from the gap
This missing record proves no first-pixel, sandbox or server-authorization failure. The unobserved stage remains narrowly defined. Even a stale-looking UI needs separate document, response and presentation evidence for causation.
Lifecycle observations
No rollback inference from one missing record
Owner/correlation review
Gap scope: confirmation observation only
Evidence conclusion
Outcome unknown
Browser confirmation remained unknown
Confirmation receipt remains UNKNOWN for this review. The normal fixture’s true value remains an expectation, not an actual observation. An absent event and a negative acknowledgement are different outcomes.
Lifecycle observations
No rollback inference from one missing record
Owner/correlation review
Gap scope: confirmation observation only
Evidence conclusion
UNKNOWN: browser confirmation receipt
New evidence was bounded to targeted correlation
Further review needs navigation-scoped association between commit and acknowledgement without full page content or user identity. Complete navigation/presentation is not declared before a new receiver observation exists.
Lifecycle observations
No rollback inference from one missing record
Owner/correlation review
Gap scope: confirmation observation only
Evidence conclusion
Needed: navigation-scoped receiver acknowledgement

IMPLEMENTATION · SECURITY CONTROL · VERIFICATION

Keep lifecycle measurements separate

This artifact is a milestone ledger for the selected navigation model. response-ready, renderer-selected, commit-delivered and confirmation-received belong to distinct owners. Network-service preparation is not browser receipt; renderer commit knowledge is not browser confirmation. Fragment and download branches require no new HTML commit. Defensive telemetry may need separate correlation fields for a request, navigation and presentation. A request ID identifies an exchange, not necessarily a document or entire user session. Linking client navigation observations to a server trace requires an explicit design. The ordinary A-to-B artifact retains response readiness, commit delivery and confirmation as separate records.

Error handling can use that distinction too. A successful download should not create an error merely because no new DOM appears. An interactive document failing a later data request does not mean its initial navigation never committed. This lesson adds no monitoring backend; it first teaches which signal can answer which question.

Browser isolation and application policy work together

Browser process and sandbox boundaries reduce the platform impact of untrusted content. Application tenant, object and action decisions belong to another layer. Browser behavior and policy are evaluated alongside server authorization. Sharing a process is not a permission proof, and using separate processes is not an API data-security proof.

Read source HTML, parsed DOM, application state and visible output separately when examining browser state. Correctness in one does not establish correctness in every other. Explaining each state owner and its change point shows which steps support the visible result.

NOW APPLY IT TO THE CASE

How do HTML commit, fragment navigation and download produce different evidence?

Ordinary HTML navigation moves from document A to B through commit and confirmation milestones. Fragment summary retains A; selected attachment creates no new HTML document. The lifecycle ledger is not first-pixel or actual-network measurement.

Order response receipt, parsing, callbacks and visible DOM outcome in the case. Try explaining the retained old title through this lesson’s browser-state distinctions.

Open the related case file ↗

READ THE EXAMPLE TOGETHER

Navigation / document / presentation ledger

Select a field and examine what it supports and where the evidence ends.

Read the raw artifact and field explanations

{
  "profile": "Selected Chromium-style coordination; aliases are not process allocation guarantees",
  "initialDocument": "A",
  "cases": [
    {
      "case": "normal",
      "newDocument": "B",
      "responseKind": "HTML",
      "commitDelivered": true,
      "confirmationReceived": true,
      "pixelsMeasured": false
    },
    {
      "case": "same-document",
      "newDocument": null,
      "retainedDocument": "A",
      "fragment": "summary",
      "networkFetchRequired": false,
      "pixelsMeasured": false
    },
    {
      "case": "download",
      "newDocument": null,
      "retainedDocument": "A",
      "responseKind": "selected-attachment",
      "downloadSelected": true,
      "pixelsMeasured": false
    }
  ],
  "normalEvents": [
    "response-ready",
    "renderer-selected",
    "commit-delivered",
    "confirmation-received"
  ],
  "actualNetworkExecuted": false
}

newDocument: B for the branch that creates a new document; null otherwise.
confirmationReceived: Separate acknowledgement before browser UI/state update.
pixelsMeasured: False: lifecycle evidence does not measure first pixels.

Synthetic selected Chromium-style coordination. No PID/IPC wire/network/readiness-event/pixel capture. Same-document fixture selects an existing fragment; allocation across browsers and platforms is not generalized.

Two reality checks

Every tab is exactly one renderer process.

Process allocation depends on document relationships, isolation and platform; tab count alone is insufficient.

Commit or load proves the exact first-pixel instant.

Commit records a document transition and load a lifecycle boundary; presentation requires another observation.

YOUR TURN

Work through this story.

Predict the outcome, find the evidence boundary, and explain it in your own words.

Does the #summary same-document branch create Document B?

Yes; every URL-fragment change requires a new HTML response.
No; Document A is retained.

Read the explained answer

No; Document A is retained. — newDocument=null and networkFetchRequired=false; this branch is not a cross-document commit.

What document outcome does the selected attachment/download response show?

Selected lesson artifact fields; teaching example

cases[2]: {"case":"download","newDocument":null,"retainedDocument":"A","responseKind":"selected-attachment","downloadSelected":true,"pixelsMeasured":false}

Download is selected; Document A remains and no new Document exists.
Every response replaces the current browser Document.

Read the explained answer

Download is selected; Document A remains and no new Document exists. — ResponseKind is selected-attachment; this branch does not turn download selection into page replacement.

The normal branch shows response-ready→commit-delivered→confirmation-received. Why does this not guarantee pixels or exact process allocation?

Read the explained answer

The selected Chromium-style model illustrates document commit/confirmation boundaries. pixelsMeasured=false; screenshot/paint completion is not observed here. Actor aliases do not guarantee process-allocation policy; actualNetworkExecuted=false prevents real navigation-timing conclusions.

□ I did not count commit as a pixels measurement.

□ I inferred no exact process guarantee from an actor alias.

Open the application console · request / response / browser

Also open request, URL, cookie and DOM examples

MANUAL LAB

Browser Observation Lab

Predict Document, DOM/CSS, and event-loop results in 18 fields, record native Browser observations, and explain why.

Open the prediction → observation → explanation workbook ↗Source on GitHub ↗

Sources and scope

Chromium: Process Model and Site IsolationGoals; Abstractions and Implementations; Modes and Availability; Origin Isolation
WHATWG HTML: navigation and history7.4 navigation; Fragment navigations; URL and history update steps; Finalize a same-document navigation
Chrome: navigation overview (2018 implementation history)Start navigation; Find a renderer process; Commit navigation; Initial load complete
Chromium RenderingNG architectureCPU processes; Threads; Rendering pipeline structure
Document readyStateValue: loading, interactive, complete
Window load eventload versus DOMContentLoaded; resource scope
Document DOMContentLoaded eventDeferred and module scripts; stylesheet relation; checking readyState

YOUR NOTES / THIS BROWSER

Browser processes and navigation

1. Core · Mechanism

HTML commit

Fragment · same DOM

File · no new DOM

A browser is an application environment

Separate processes and threads

Tab count is not process count

Navigation intent, response and commit

A URL can change within the same document

Commit, readiness and pixels are separate gates

2. Red · Trust & Impact

Commit scope

Download branch

Ask who owns the signal

Separate navigation evidence from content decisions

3. Blue · Secure development & defense

Milestone review

Confirmation gap

Keep lifecycle measurements separate

Browser isolation and application policy work together

How do HTML commit, fragment navigation and download produce different evidence?

Two reality checks

Does the #summary same-document branch create Document B?

What document outcome does the selected attachment/download response show?

The normal branch shows response-ready→commit-delivered→confirmation-received. Why does this not guarantee pixels or exact process allocation?

Browser Observation Lab

Sources and scope