Firefox in Wasm Is a Nested Browser Demo

Running a full browser engine inside another browser used to live in research papers and late-night hacks. Puter's demo of the Gecko engine compiled to WebAssembly puts a real Firefox interface, complete with its chrome and rendering, into a single browser tab. It is not vaporware. It launches, draws web content, and accepts input.

The stunt works because WebAssembly has matured far enough to host large C++ codebases with near-native speed, isolated memory, and WebGL for graphics. That does not make it production infrastructure. It is a high-fidelity proof that nested browsers are now technically feasible, useful for isolation experiments and constrained testing, and still too constrained for most day-to-day developer workflows.

What the demo actually does

The page boots a prepared Firefox build that runs entirely as Wasm. The real interface appears inside the host tab. Advanced options expose three knobs that reveal the engineering choices:

• GPU acceleration uses WebGL-based rendering for web content.
• An experimental JS-to-WASM JIT can be toggled, with an explicit warning to expect bugs.
• Networking is not direct. Tabs load content through a Wisp server, a WebSocket proxy hosted by Puter. Puter.js powers the networking layer inside the sandboxed instance.

Startup produces a visible log. The whole stack sits inside the host browser's security model, so the nested Firefox inherits Wasm's linear memory isolation and cannot freely touch the host filesystem or raw sockets.

This is the inverse of Mozilla's earlier work sand-boxing individual Firefox components with WebAssembly (RLBox and ahead-of-time Cranelift compilation). There the goal was hardening small libraries such as Graphite. Here the entire engine becomes the guest.

Why it is more than a curiosity

WebAssembly already proved it can run games, media tools, and scientific code at usable speeds by pairing a portable binary format with WebGL and careful memory management. Compiling Gecko is a larger claim: a modern layout engine, JS runtime, and UI chrome can be treated as just another Wasm module.

For security-minded developers the attraction is obvious. Process isolation is expensive and coarse. A Wasm-hosted browser instance gives a second, language-level sandbox without spinning up a full OS container. Content rendered inside it is mediated by the proxy and the host's origin policies. That is attractive for untrusted previews, student sandboxes, or multi-tenant tools that need to display arbitrary pages without giving them a real browser process.

It also lowers the bar for "browser as a library." Instead of embedding a headless Chromium via Puppeteer or Playwright and paying the process and IPC tax, a sufficiently complete Wasm Firefox could be instantiated, scripted, and torn down inside the same page that needs it. The experimental JIT and WebGL path show the performance path is being explored, even if both are still rough.

What a developer can actually do with it today

Adoption is not a package install. You open the hosted demo, wait for the prepare step, and launch. There is no published CLI, no npm install gecko-wasm, and no documented API for driving the instance from host JavaScript beyond whatever Puter.js exposes for networking.

Practical experiments that make sense right now:

• Manual visual checks of pages under a second engine without installing Firefox.
• Teaching or demos of browser architecture: students can watch a full engine boot and fail in a controlled tab.
• Isolation spikes: load untrusted HTML through the Wisp proxy and observe that the guest cannot reach the host origin directly.

What does not work yet for production:

• Automated test suites. No stable remote protocol equivalent to Chrome DevTools Protocol is advertised, so you cannot script clicks, assertions, or screenshots the way you do with Playwright.
• Direct network access. Everything funnels through Puter's Wisp server. That adds latency, breaks some WebSocket or CORS patterns, and makes the setup dependent on a third-party proxy.
• Performance parity. Layout, JS execution (especially with the experimental JIT off), and compositing will be slower than native Gecko. Expect bugs when the JIT is on.
• Persistence and filesystem. Standard Wasm sandbox rules apply: no host filesystem, limited storage only through host Web APIs if the glue code provides them.

If the project ships a self-hostable build, a documented embedding API, and a way to run without the external Wisp dependency, the calculus changes. Until then treat it as a live research artifact rather than a drop-in tool.

Trade-offs versus the alternatives

Headless Chrome or Firefox via Playwright remains the default for CI and regression testing because it is scriptable, network-transparent, and close to the real user agent. Containerized browsers (Browserless, Selenium Grid) give process isolation at higher resource cost. Service workers and sandboxed iframes are lighter but cannot run a full engine.

The Wasm approach sits in a different niche: maximum code reuse of an existing engine with language-level memory safety and no extra processes. The cost is the proxy requirement, incomplete feature surface, and the fact that you are still running a browser inside a browser, so double the rendering stack in memory.

Mozilla's own Wasm work shows the same engine can be both host and guest. That symmetry is interesting for future multi-engine testing ("does this page look the same under nested Gecko?") but does not yet replace dual-browser CI matrices.

Where this heads

The demo proves the hard part (getting Gecko to compile and paint under Wasm) is solvable. The remaining gaps are glue: stable networking without a central proxy, a real automation surface, and performance work on the JS and graphics paths. If those close, nested browsers become a practical primitive for sandboxed previews, education, and specialized isolation tools. If they stay open, the project remains an impressive Show HN that demonstrates how far WebAssembly has come since Firefox first shipped support for it.

For most developers the right action today is to open the page, poke the advanced options, and file the idea under "watch." The engineering is real. The product surface is not ready to replace anything in a shipping pipeline.