...Mozilla is refusing to implement it for not other reason than... I really don't know what their reasons are.
Probably because NaCl blasts way beyond a leaky abstraction into hard-coded dependency on a specific processor. Mozilla (I'm guessing) wants the web to be a leak-proof abstraction. There are half a dozen different architectures on which one may want to run Firefox (x86/x86-64, PPC, ARM, Sparc, MIPS, etc.). NaCl requires in-depth security analysis and implementation for each platform, plus every web developer would have to compile and test a version of their code for every platform (or, more likely, they'll just support x86, maybe ARM).
PNaCl using LLVM would be slightly better, but WebCL is probably the best approach to number crunching in web apps. Security is also easier at a higher level of abstraction.
Surely you mean x86. Firefox Mobile for Android (ARM) has been out for months. And x86_64 builds are already in existence and are slated for Firefox 8.
Firefox has x86, x86-64, and ARM as tier-1 architectures.
It has a whole bunch of tier-2 architectures that are supported but to a lesser extent (e.g. a patch that breaks one of them doesn't automatically get backed out immediately). People are shipping and using Firefox on various of those architectures, including JS jits on at least Sparc and PPC.
Probably because NaCl blasts way beyond a leaky abstraction into hard-coded dependency on a specific processor. Mozilla (I'm guessing) wants the web to be a leak-proof abstraction. There are half a dozen different architectures on which one may want to run Firefox (x86/x86-64, PPC, ARM, Sparc, MIPS, etc.). NaCl requires in-depth security analysis and implementation for each platform, plus every web developer would have to compile and test a version of their code for every platform (or, more likely, they'll just support x86, maybe ARM).
PNaCl using LLVM would be slightly better, but WebCL is probably the best approach to number crunching in web apps. Security is also easier at a higher level of abstraction.