A browser page can display its shell while the JavaScript and CSS that make the application run have already failed to load. In Bartosz Osiej’s account of Aurora, that split produced a convincing but incorrect “Initializing kernel…” hang: the deployed HTML referenced dist/main.js and dist/style.css, yet both files were absent from the published tree and returned 404 responses. After the bundle was made available, a separate full-screen layer still sat above the desktop and intercepted every click.
The practical diagnosis is to work from the outside in. First verify the deployed asset requests and publishing directory. Only then inspect application startup. If controls are visible but inert, inspect hit-testing, stacking order and pointer-events before blaming the window manager or a kernel routine.
As an Amazon Associate I earn from qualifying purchases.
What failed in Aurora
Aurora is described as a TypeScript, browser-based operating system with a window manager, virtual file system, terminal and eight apps. The project uses no runtime dependencies. Its interface looked like an operating system, so a spinner that stopped on “Initializing kernel…” naturally suggested a low-level boot failure. Osiej’s postmortem identifies two ordinary web-platform failures instead: missing build artifacts and an invisible element claiming pointer input.
Free tools Windows power users keep installed
One-click scans. No signup required.
The first failure was a missing bundle
The page’s HTML pointed at dist/main.js and dist/style.css. In the setup described by Osiej, the dist/ directory was ignored by Git. The GitHub Pages configuration served the committed repository tree and did not run npm run build as part of publishing. The result was a valid HTML shell with no deployed JavaScript bundle and no deployed stylesheet at the paths the browser requested.
#1 Best Overall
Because the boot sequence was waiting for code that never arrived, the visible state remained “Initializing kernel…”. The label described the last stage the application had reached, not the cause of the failure. A 404 for the bundle—not a defective kernel—explained the apparent hang in this account.
The second failure was a hit-testing problem
Once the built files were available, desktop icons still did not open applications. The reported cause was #windows-layer: a full-viewport container positioned above the icon grid with a positive z-index. It was transparent, but transparency affects appearance, not input eligibility. Since the layer remained eligible for pointer events, it intercepted clicks before they reached the icons underneath.
Osiej’s proposed pattern is to make the structural, full-screen container click-through with pointer-events: none, then opt the actual interactive window elements back in with pointer-events: auto. That preserves visual stacking while allowing controls below or inside the layout to receive input.
Start with the network request, not the “kernel” label
When a web application appears stuck during startup, the browser’s Network panel gives a more reliable first answer than the text rendered by the application. The following sequence matches the checks recommended for this incident.
Rank #2
- Open developer tools before reloading. Use the browser’s developer-tools shortcut, select the Network panel, enable logging if the browser offers that option, and reload the deployed page.
- Filter for JavaScript and CSS. Look for the requests corresponding to every script and stylesheet in the HTML, especially
dist/main.jsanddist/style.cssin Aurora’s case. - Read the status and final URL. A 404 means the server answered but the requested path was not present. Also check whether the browser requested a different base path than you expected, such as a repository subdirectory.
- Open the request directly. The response body and URL reveal whether the path contains the intended built file, an HTML fallback page, or an error response. A successful document request does not prove that its dependent assets succeeded.
- Repeat after every deployment. Walk the deployed asset tree and compare it with the paths written into the published HTML. Do not rely only on a local build directory or a successful local development server.
| What you see in Network | What it establishes | Next check |
|---|---|---|
| HTML is 200; JavaScript is 404 | The shell arrived, but application code did not. | Verify the published directory, build output and script path. |
| HTML is 200; CSS is 404 | The page may render unstyled while script behavior remains independent. | Verify that the stylesheet was generated and copied to the URL in the HTML. |
| Both built files are 404 | The deployment likely contains source files but not the expected build output, or the base path is wrong. | Inspect the repository tree and publishing configuration together. |
| Built files are 200 but controls are inert | Startup assets arrived; the remaining fault may be event routing or hit-testing. | Inspect the elements above the control and their pointer-event rules. |
Make the build and publishing arrangement explicit
The Aurora incident came from an implicit assumption: the project had a generated dist/ directory locally, so the author expected the hosting service to expose it. The described Pages setup instead served committed files and did not execute the build command. Whether that happens on another Pages site depends on its selected source and build configuration; it is not a universal rule that every Pages deployment behaves the same way.
There are two valid arrangements. Choose one deliberately and make the resulting URL tree observable.
| Arrangement | What is published | What you must verify |
|---|---|---|
| Commit build output | The repository contains the generated files, and the publishing source serves that directory or its contents. | Confirm that each HTML-referenced file, including every dist/* path, is present in the committed tree and at the deployed URL. |
| Generate during publishing | The publishing workflow runs the project build and publishes the directory it produces. | Confirm the build command runs in the deployment environment and that the configured output directory is the one actually served. |
For the second arrangement, a deployment log that says “build succeeded” is not enough. The output directory can be correct locally but omitted from the upload, or the site can publish a different directory. The decisive test is the deployed asset URL: request the exact path emitted by the HTML and check that it returns the intended file.
Check base paths as well as filenames
A file can exist in the repository and still be missing at the URL the browser uses. Repository-hosted sites often live below a project path, so an absolute reference such as /dist/main.js can point at the host root while the file is actually under a project subdirectory. The postmortem centers on absent dist/ files, but the same Network-panel method catches a wrong base path: compare the request URL with the location of the file in the published tree.
Rank #3
Why a transparent overlay can block every icon
After startup works, a desktop that looks normal can still be non-interactive. Browsers dispatch pointer input using the rendered hit-test order, which is influenced by layout, positioning and stacking contexts. A transparent element remains a hit-test candidate unless its pointer behavior says otherwise.
Inspect the topmost element under the pointer
- Use the element picker. In developer tools, select the icon or button that appears unresponsive. The inspector should reveal which node is actually under the pointer.
- Check the computed geometry. Look for a fixed or absolute element spanning the viewport, such as
#windows-layer, and confirm its width and height cover the desktop. - Check stacking order. A positive
z-indexon a positioned layer can place it above the icon grid even when the layer has no visible background. - Check pointer eligibility. In the computed styles, inspect
pointer-events. The default behavior leaves ordinary elements eligible to receive pointer input; opacity or a transparent background does not change that. - Test with the layer disabled. Temporarily uncheck the suspected layer’s display or pointer rule in developer tools. If the icon immediately responds, the problem is event interception rather than the icon’s handler.
Apply the click-through pattern
The fix described for Aurora keeps the full-screen layout layer in the visual tree while removing it from pointer hit-testing. Interactive windows are explicitly enabled again:
#windows-layer {
pointer-events: none;
}
#windows-layer .window {
pointer-events: auto;
}The selector for the interactive child must match the project’s actual window elements. If the windows are nested differently, apply pointer-events: auto to the element that owns their controls. The important distinction is structural surface versus interactive surface: the former should not claim clicks merely because it covers the viewport; the latter must remain eligible.
Recommended Free Tools
| Layer type | Recommended hit-testing behavior | Reason |
|---|---|---|
| Full-screen layout container | pointer-events: none |
Lets pointer input pass through areas that contain desktop icons or other controls. |
| Actual application window | pointer-events: auto |
Allows window chrome, buttons and content to receive events. |
| Decorative overlay with no controls | Usually pointer-events: none |
Prevents invisible decoration from becoming an accidental input surface. |
Changing z-index alone can hide the symptom by moving the layer behind other content, but it can also break the intended window stacking order. The pointer-events rule addresses the input responsibility directly and leaves visual ordering available for windows that need to appear above the desktop.
A deployment-to-interaction troubleshooting playbook
Use this order when a browser OS appears not to boot and then appears not to respond.
- Reproduce on the deployed URL. A local development server may build files automatically, while the published site may serve a static tree.
- Capture the initial requests. Record the status and exact URL for the HTML, JavaScript bundle and stylesheet. Treat each request independently.
- Locate the published files. Inspect the branch, artifact, or output directory selected for publishing. Confirm that the generated files are included there rather than only in an ignored local directory.
- Verify the publishing command or source. Decide whether deployment commits build output or generates it. In the incident described, the Pages source served repository files and did not run
npm run build. - Redeploy and recheck the URLs. A successful page load is not the acceptance test; the referenced assets must return the expected files.
- Only after assets load, debug application startup. Use console errors, breakpoints and initialization logs once the browser has received the code that produces them.
- If the desktop renders but clicks fail, inspect hit-testing. Identify the topmost element, its bounds, stacking order and
pointer-eventsvalue. - Separate layout from controls. Make non-interactive full-screen layers click-through and restore pointer handling on real windows and controls.
- Retest different regions. Verify a desktop icon, a window title bar, a button inside a window and any draggable area. This catches an overly broad rule that fixes one target while disabling another.
Common wrong turns and their safer alternatives
Assuming the last visible label names the defect
“Initializing kernel…” is application text. It does not prove that kernel code ran, nor that a kernel routine is responsible for the pause. Inspect dependent requests first.
Debugging source files when the deployed site serves artifacts
TypeScript source and a local dist/ directory do not guarantee that those artifacts were uploaded. Debug the URL users receive, then align the build and publish settings with that URL.
Treating transparency as click-through
An element with no visible pixels can still receive pointer input. Use computed styles and the element picker rather than judging from appearance.
Removing the window layer entirely
Deleting a layer may restore icon clicks while destroying the window manager’s stacking and interaction model. Keep the layer, make its structural portion non-interactive, and opt interactive windows back in.
Changing several variables at once
For a 404, change one publishing or path assumption, redeploy, and recheck the request. For a click problem, toggle the suspected layer’s pointer rule and retest. Isolating one change preserves a useful cause-and-effect trail.
What this postmortem does—and does not—establish
These details come from Bartosz Osiej’s first-person account, identified in the source as an October 11 DEV Community post originally published at bo.hartwell-labs.pl. They describe the Aurora setup and the fixes the author proposed; they are not an independently reproduced benchmark or a general guarantee about every GitHub Pages configuration.
The Tool Desk
Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →The project description mentions eight apps and more than 35 terminal commands. Those are counts attributed to the article’s description of Aurora, not external statistics about browser operating systems. The useful general lesson is narrower and more durable: a web application’s document, assets and input layers fail independently, so each layer needs its own check.
Quick Recap
Deployment and hit-testing checklist
- Open Network tools before reloading the deployed page.
- Check every HTML-referenced JavaScript and CSS URL, including its status and final path.
- Confirm the generated output is either committed or produced by the publishing workflow.
- Confirm the publishing source serves the directory that contains those files.
- Walk the deployed asset tree after each deployment.
- Do not infer a kernel defect from a spinner or “Initializing kernel…” label alone.
- When visible controls do nothing, identify the topmost element under the pointer.
- Inspect viewport-sized layers, positioning, stacking order and computed
pointer-events. - Set structural full-screen layers to
pointer-events: nonewhen they should not receive input. - Set
pointer-events: autoon the actual interactive windows and verify each control type separately.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
