Firefox in WebAssembly: Porting a Browser to WASM

Firefox in WebAssembly: Porting a Browser to WASM

Firefox in WebAssembly Overview

Firefox in WebAssembly is a technical demonstration that ports the Firefox browser engine to WebAssembly (WASM), allowing a full browser to run inside another web browser. The project implements GPU acceleration via WebGL-based rendering for web content and includes an experimental JavaScript-to-WASM Just-In-Time (JIT) compiler to improve execution speed.

Technical Architecture and Implementation

Rendering and Execution

  • GPU Acceleration: The project utilizes WebGL to handle the rendering of web content, providing hardware acceleration within the WASM environment.
  • Experimental JIT: To address performance, the project includes a JS $\rightarrow$ WASM JIT compiler. The developer notes that this feature is experimental and may contain bugs.
  • Networking: Web content is not loaded directly by the WASM instance; instead, it is proxied through a Puter-hosted Wisp server via WebSockets. This architecture means that network traffic originates from the proxy server rather than the user's local machine.

Compatibility and Requirements

  • JSPI Support: The project requires WebAssembly JavaScript Promise Integration (JSPI) to function. Users running browsers that do not support JSPI will be unable to load the demo.
  • Recursive Execution: The author confirmed that it is technically possible to run "firefox-wasm inside firefox-wasm inside firefox," although the system becomes highly unstable at this level of recursion.

Community Insights and Technical Challenges

Performance and Development Cost

Development of the port involved significant investment in AI-assisted coding. The author mentioned that the port cost over "25k in opus/fable tokens for debugging and JIT research," highlighting the role of LLMs in complex porting tasks.

Security and Privacy Concerns

Community members have raised concerns regarding the proxy-based networking model. Because traffic is routed through a Puter-hosted server, the user's IP address is masked, and the server owner has visibility into the traffic.

All the network traffic from that browser is routed through a server. My IP inside that browser was in India and on CloudFlare network. I don’t particularly trust Puter.

Practical Use Cases and Limitations

Users have identified several potential applications and limitations of the port:

  • Bypassing Restrictions: Some users suggest using this to run ad-blockers (like uBlock Origin) on locked-down OS environments (e.g., VIDAA OS) where the native browser prohibits extensions.
  • Mobile Support: The project currently lacks robust mobile support. Reported issues include non-functional IMEs/keyboards, broken copy-paste functionality, and touch-scrolling failures on Android Chrome.
  • Stability: Some users reported SecurityError and unsupported syscall: __syscall_madvise errors when attempting to run the demo on specific browser versions (e.g., Firefox 152.0.6 on aarch64).

Comparison to Prior Art

Technical discussions pointed to WebKit.js as a prior example of the WebKit rendering engine being ported to JavaScript, suggesting a trend toward embedding full rendering engines within the web platform.

Sources