The local inspector returns recovery for a rejected navigation only, while 404 and 500 keep their server response identities. Failed images do not receive HTML. The recovery design includes a single explicitly simulated retry; no service worker, cache or network request is created by the example.
Work through the example
Select HTTP 404 and the result preserves 404 instead of displaying “You are offline.” Select Navigation rejected to show the cached-recovery scenario. Missing cache holds recovery readiness. The Retry simulation counts one local attempt per activation and says no request occurred; real retry navigation belongs in the native offline document.
Test navigation rejection separately from HTTP errors and subresource failures. A recovery design does not establish worker control or cache readiness. The actual fallback must already be cached for the intended worker version and scope. Preserve a usable single retry action without polling, and verify the returned body/status in the native integration rather than inferring status from a page heading.
Define the KitPortal recovery packet
Prepare three files for the real site: note.html, a self-contained offline.html, and service-worker.js. The first is the intended document; the second explains a fetch failure; the third contains the later native interception and caching behavior.
Plan to pre-cache the recovery document before relying on it. Its essential text, styling, and Retry behavior should not depend on an uncached remote font, image, or script. The web.dev fallback guide describes pre-caching a recovery document for failing navigations and accounting for every resource that it needs.
Record the intended worker version, script URL, scope, cache identity, and recovery asset revision. Those are planned fields until inspected in the browser. A file named offline.html on a server does not establish that the current client can retrieve it from a cache.
Choose the response by request and outcome
The request's mode and the fetch outcome are separate inputs. MDN documents the Request exposed by a fetch event and notes that HTTP errors such as 404 return response objects rather than causing fetch exceptions. See FetchEvent.request. A handler that turns every non-success HTTP status into an offline page would violate this fixture's policy.
When testing later, inspect the actual returned status and body. A heading saying “Request unavailable” does not establish its HTTP status. Conversely, preserving a 500 response does not mean the page content is useful; it means the original server outcome has not been relabeled as a network exception.
Check control and cache before claiming recovery
A first visit made without the required initial network access cannot establish that the recovery document was pre-cached. A registered worker also needs the intended scope and actual client control. Hold readiness until native evidence shows the active worker and cached recovery asset used by the target navigation.
Service workers require a secure context and registration rules tied to the page's origin and scope. The worker is a real native JavaScript file, not an HTML preview. MDN's service worker overview and registration reference explain these requirements. Keep the exact deployed URLs and browser behavior pending instead of claiming that a prepared packet already controls a site.
Before relying on recovery, check the initial cache population, active worker version, client control, recovery asset and each dispatch case.
Write copy that matches the evidence
Use this proposed recovery wording:
KitPortal could not fetch this page.
The requested page is unavailable right now. Check your connection or try again when you are ready.
Retry this page
It describes the failed request without claiming the entire device or internet connection is offline. Plan one explicit Retry control that attempts the original navigation once per user activation. If it still fails, retain a readable recovery state. Do not add an automatic reload or polling loop to this fixture.
Recreate this example
Build one self-contained responsive HTML example titled “Offline page HTML: explain a failed navigation” for readers completing the stated task. Return the complete HTML with embedded CSS and JavaScript. Use no remote fonts, libraries, images, requests, account connections, or saved-state claims.
Original KitPortal recovery wording: KitPortal could not fetch this page. Requested page unavailable right now; check connection or try again when ready. Show recovery design and buttons Navigation rejected, HTTP404, HTTP500, Image failed, Missing cache. Dispatch only navigation fetch rejection with cached fallback to recovery; preserve404/500; no HTML image substitution; missing cache holds. Retry simulation increments one local count per click, clearly no network/navigation. Include copyable native retry instruction one location.reload per user button, no polling; worker/cache/control tests remain separate. No offline submit/saved-work claim.
Use a calm recovery-page design alongside a dispatch-case inspector design with a compact header. Keep the actual sample data, controls, and useful default result visible early on a 360px-wide screen. Use readable text at least 16px, generous paragraph spacing, strong contrast, semantic labels, visible keyboard focus, and wrapping source blocks. Stack records on narrow screens rather than forcing a wide table.
Wire each action to an explicit type=button click handler using element selectors; the host permits scripts but blocks form submission. Update the visible result when the described action occurs. Show specific error feedback for invalid or missing input and clear stale feedback after dependent inputs change. Use plain text when displaying user values.
Dispatch scenarios and retry simulation do not register a service worker, populate caches or perform a navigation. Keep the source fixture and worked teacher or developer example distinct from actual user records. Include the domain-specific explanation and next check beside the result. Provide no fake download, send, deployment, approval, or persistence button. Everything operates locally for the current page session.
Review the prepared copy in NOS
Implement and test the real recovery document and worker in their authorized host. For a separate copy review, NOS can render the HTML explanation and permit visual changes to eligible static recovery wording. Keep cache, control and dispatch observations with the native files.