Firefox gira dentro Chrome: Gecko diventa un'app WebAssembly

Un Firefox completo eseguito dentro una scheda aperta con un altro browser potrebbe sembrare fantascienza. In realtà, a realizzare il progetto open source – battezzato firefox-wasm – è stato HeyPuter, già noto per aver trasformato il browser in una sorta di sistema operativo con interfaccia grafica. A luglio 2026, gli sviluppatori hanno portato il motore Gecko utilizzato da Firefox per il rendering dei contenuti e l’interfaccia reale del browser Mozilla in WebAssembly.

WebAssembly debuttò nei principali browser web nel 2017 come formato binario portabile, pensato soprattutto per trasferire sul web software scritto in C, C++ e altri linguaggi compilati. Da allora sono arrivati SIMD, memoria condivisa, operazioni atomiche, garbage collection e varie estensioni che hanno reso possibili applicazioni molto più complesse. Portare Gecko nel browser resta comunque un salto notevole: Firefox comprende milioni di righe di codice, un motore JavaScript, librerie grafiche, gestione dei font, rete, processi, thread e numerosi componenti che normalmente dipendono dal sistema operativo.

Firefox dentro Firefox, Chrome, Edge o un altro browser

La demo di Puter Labs mostra la vera interfaccia di Firefox racchiusa in una normale pagina web: l’utente può avviare il browser, inserire un indirizzo e caricare contenuti senza avviare un eseguibile tradizionale. Il rendering avviene nella scheda ospitante, con un’opzione per attivare l’accelerazione grafica basata su WebGL.

La distinzione rispetto a un browser remoto è importante. Nei servizi di browser isolation più comuni, Firefox o Chromium girano su un server e trasmettono al client immagini, video o comandi grafici. Qui Gecko gira localmente come modulo WebAssembly: il server interviene soprattutto per la connettività, perché una pagina web non può aprire liberamente socket TCP e UDP verso qualunque destinazione Internet.

In pratica, si crea una situazione insolita: il browser esterno fornisce il runtime WebAssembly, i Web Worker, la superficie grafica e le API consentite dalla piattaforma web; al suo interno Gecko interpreta HTML, CSS e JavaScript delle pagine visitate.

Come Gecko viene trasformato in WebAssembly

Il porting si appoggia a Emscripten, toolchain basata su LLVM che converte programmi C e C++ in WebAssembly e genera il codice JavaScript necessario per integrarli nel browser.

Il repository GitHub non incorpora una copia completa del sorgente di Firefox: la scelta degli sviluppatori rende la build riproducibile e impedisce che un aggiornamento casuale del ramo principale di Mozilla introduca modifiche incompatibili. Servono Linux, Node.js, pnpm, Python, Rust con il target wasm32-unknown-emscripten e le dipendenze audio di PulseAudio. macOS, almeno nelle istruzioni iniziali, non è supportato come ambiente di compilazione.

Una normale installazione di Firefox accelera JavaScript attraverso più livelli di esecuzione. SpiderMonkey parte da interpreti relativamente semplici, raccoglie informazioni durante l’esecuzione e può infine generare codice macchina ottimizzato. Dentro WebAssembly, però, Gecko non può scrivere liberamente istruzioni native nella memoria e poi eseguirle. Le tradizionali tecniche di JIT compilation entrano quindi in conflitto con il modello di sicurezza del browser ospitante.

La configurazione standard disattiva quindi il JIT di SpiderMonkey e abilita il Portable Baseline Interpreter: l’impostazione risulta più veloce dell’interprete bytecode più elementare, ma non può offrire le prestazioni dei livelli JIT disponibili nella versione desktop.

HeyPuter sta sperimentando anche una soluzione JS-to-Wasm JIT: invece di emettere istruzioni x86-64 o ARM, il motore tenta di trasformare il codice JavaScript in nuove funzioni WebAssembly. L’idea ha senso, perché il browser ospitante può validare e compilare il modulo prodotto. Il punto è che generare, collegare e sostituire dinamicamente funzioni Wasm richiede meccanismi diversi da quelli progettati storicamente per SpiderMonkey.

WasmFS e l’illusione di un sistema operativo

Firefox si aspetta file di configurazione, font, librerie, profili, cache e molte altre risorse. Nel browser non dispone di un file system POSIX tradizionale: Emscripten offre quindi WasmFS, un livello che presenta al codice compilato operazioni simili a open, read, write e stat, traducendole in strutture mantenute nella memoria del runtime o in backend compatibili con il web.

firefox-wasm abilita inoltre le istruzioni WebAssembly SIMD a 128 bit: Gecko può così accelerare percorsi usati da Skia (libreria grafica 2D open source scritta in C++), decodifica delle immagini, conversione dei colori, operazioni di memoria, Stylo e WebRender. Senza SIMD molte routine ricadrebbero su implementazioni “basiche”, con un impatto evidente in un browser già penalizzato dall’assenza del JIT nativo.

Perché il progetto è importante anche se imperfetto

firefox-wasm dimostra che un motore browser general purpose può diventare una libreria web caricabile all’occorrenza.

Le possibili applicazioni vanno oltre la curiosità di aprire Firefox dentro Chrome: test di compatibilità senza installazioni, ambienti didattici, editor web con rendering Gecko integrato, laboratori di sicurezza isolati, piattaforme cloud e strumenti capaci di confrontare più motori nella stessa sessione.

Potrebbero nascere anche servizi di automazione eseguiti quasi interamente sul client, evitando di mantenere un’istanza browser per ogni utente sul server. Restano però ostacoli concreti: dimensione degli asset, tempi di avvio, consumo di memoria, compatibilità dei siti, prestazioni JavaScript.

Firefox in WebAssembly non può rimpiazzare il browser installato sul computer. Eppure la demo di HeyPuter funziona bene da rendere concreta un’idea che pochi anni fa sarebbe sembrata poco realistica: distribuire non soltanto una pagina o un’applicazione, ma un intero browser, con il suo vero motore, attraverso una normale pagina web.