This is the entire Firefox browser rendering to a <canvas> element. Gecko, all UI components, and the Spidermonkey JS engine are all compiled and running in WebAssembly.
Here are a few things you might find interesting:
- This is fully end to end encrypted! We use the WISP protocol for TCP-over-websockets.
- There is a novel WASM->JS JIT for experimental site speedup
- This port cost over 25k in opus/fable tokens for debugging and JIT research
This was just a fun experiment to push the boundaries of WebAssembly. For a more usable "browser in browser" experience, we also built https://github.com/HeyPuter/browser.js that eats a bit less RAM.
I'm so glad this exists, I've been considering doing something like this for a few months.
I recently got a TV based on VIDAA os, a locked-down linux-based OS where everything is rendered from Web pages. It has a built-in browser that doesn't support ad-blocking (I suspect VIDAA is profiting from showing ads on the TV), and you can't install new apps unless they're Web pages.
This would hopefully allow one to run Firefox within the existing browser, then install uBlock Origin within Firefox... I know what this weekend's project is going to be...
Oh and for anyone asking, you can run firefox-wasm inside firefox-wasm inside firefox! I only got this to load once though since it gets pretty unstable at that level.
I can’t help but think of Gary Bernhardt’s 2014 talk, “The Birth and Death of JavaScript”: https://www.destroyallsoftware.com/talks/the-birth-and-death...
Loosely related to porting the Firefox engine in unusual places: here is a project that ports Firefox's Gecko rendering engine to iOS as a sideloadable app (normally Apple only allows its own WebKit rendering engine in iOS apps): https://github.com/minh-ton/reynard-browser
Can’t get it running on Firefox 152.0.6 (aarch64), no extensions.
[chrome-demo] chrome assets ready
[gecko] warning: unsupported syscall: __syscall_madvise
[gecko] embed-xul: main() on the app pthread (PROXY_TO_PTHREAD)
[gecko] embed-xul: GECKO_GL_PASSTHROUGH=1
[gecko] embed-xul: GECKO_COARSE_CLOCK=1
[gecko] embed-xul: GECKO_GPU=1 (GPU/WebRender->canvas rendering)
[gecko] xul_init: GRE dir = /gre
[gecko] Pthread 0x11051000 sent an error! blob:https://developer.puter.com/edc1bd0a-b844-4a18-a69a-63dd49dc304a:8906: SecurityError: Security error when calling GetDirectoryPrior art: WebKit.js, the WebKit rendering engine ported to JS
Impressive and surprisingly performant, but what's the use-case?
If anything, this is an ad for WASM!
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. Why not route traffic through my actual browser?
I've been waiting for this to happen.
The websites that don't want you to block ads will serve you an obfuscated "inner browser" that will render their site. All your ad blockers, etc, are rendered moot.
Once accessibility is solved this is absolutely going to be a thing on major websites.
25k tokens to port Firefox to WASM. by 2027 we'll be spending 25k tokens to port WASM back to native because someone will benchmark it and find the WASM version is 3% faster.
What makes it require that WASM extension you need the flag for in Firefox? Was there really no way to work around it or polyfill it for it to work? It is performance critical?
I would be careful with this demo. When you go to whatismyip.com, it's showing: 104.28.233.73. Someone could use this to cloak their IP address and do some damage.
edit: I misunderstood, that's $25k not 25k tokens :/ time to log off.
this is so rad! 25k tokens is a lot less than i thought this'd take -- what were the difficult bits in the porting process? also, was firefox preferred because parts of it are already in rust?
> There is a novel WASM->JS JIT for experimental site speedup
I would love to see the details for this. SpiderMonkey had an attempted wasm32 JIT backend, but it was never finished.
edit: Apparently it also has some sort of WebAssembly interpreter backend too, which SpiderMonkey doesn't have.
on mobile chrome / Android I can't get the following to work :
- IME / keyboard doesn't pop on any field
- copy paste
- scrolling with touch
- ai side panel
What works on mobile :
- Extensions !
This is so sick great work; did you try webgpu?
The description mentions a similar project browser.js which apparently has some real use cases, what are they?
This is amazing. I loaded up https://developer.puter.com/labs/firefox-wasm/ in Chrome and I've visited a bunch of sites, it works really well.
Then I opened up https://developer.puter.com/labs/firefox-wasm/ in Firefox-in-WebAssembly-in-Chrome
... and sadly it didn't load. I got this in the startup log:
[log] [chrome-demo] chrome assets ready
[warn] [gecko] warning: unsupported syscall: __syscall_madviseYo dog, I heard you like browsers, so I put a browser in your browser.
"Yo dawg. I herd you like web browsers, so I put a browser in your browser, so you can browse the Web while you browse the Web".
Since coolelectronics posted his firefox wasm here ill post my sideproject (we worked on these around the same time), Webkit In WebAssembly (And actually modern and usable! Unlike the older trevorlinton/webkit.js project)
https://github.com/theogbob/WebkitWasm
Not as polished as the firefox port but is a fully working port of webkit ported with fable, opus and some glm 5.2.
Great, now I can finally make an Electron.js application with code made for Firefox!
"This browser doesn't support WebAssembly JSPI, which Firefox WASM needs to run."
>This port cost over 25k in opus/fable tokens for debugging and JIT research
> This was just a fun experiment to push the boundaries of WebAssembly
I'm a huge fan of the project, but I have to ask. If spending $25k is a "fun experiment", where exactly is your threshold for serious work?