11 ms·

Chrome and Opera Optimize for Mozilla-Pioneered Asm.js

134 points by ndesaulniers 13y ago

reissbaker 13y ago
Is this accurate? My understanding was that the V8 team wasn't explicitly optimizing for asm.js, and just optimized V8 in general (and that often asm.js hit fast-paths even without explicit optimization). It sounds from the article like Epic announced that Chrome/V8 is fast enough to run the Unreal 3 engine, and Mozilla's trying to spin it as V8 explicitly optimized for a "spec" invented by Mozilla when actually they just made V8 really, really fast. That said, they do include an asm.js benchmark in Octane 2, so it's clearly on their radar. But as far as I've heard they haven't actually implemented special asm.js typecheckers / AOT compilers like Mozilla has.
- azakai 13y ago
  Not sure where you see "spec" mentioned in there? As you say, Google included asm.js code in Octane 2, and you can see progress on asm.js benchmarks as Google optimizes in ways that help that style of code on arewefastyet, http://arewefastyet.com/#machine=11&view=breakdown&suite=asmjs-ubench http://arewefastyet.com/#machine=11&view=breakdown&suite=asm... This is also not something new, Google has optimized for asm.js code since the IO keynote much earlier this year where Google reported a 2.4x speedup on an aggregate asm.js benchmark, http://culturemass.com/2013/05/17/google-io-2013-keynote-part-ii/ http://culturemass.com/2013/05/17/google-io-2013-keynote-par... There are many ways to optimize for different types of code. Firefox uses the asm.js type system for asm.js, and does AOT compilation, while Chrome chose a different approach. The two approaches have different benefits. But both browsers certainly optimize for asm.js, they both announced doing so and the numbers are proof that they are succeeding. edit: add link to Octane 2.0 and the asm.js benchmark added there, http://blog.chromium.org/2013/11/announcing-octane-20.html http://blog.chromium.org/2013/11/announcing-octane-20.html
  - rictic 13y ago
    Even before asm.js there was emscripten (the primary generator of asm.js and inspiration for much of the spec), which has been used for a number of high profile demos and likely got optimization attention for years before asm.js.
    - cpeterso 13y ago
      I'm sure azakai is familiar with emscripten. ;)
      - girvo 13y ago
        This doesn't happen anywhere except on HN. I check parents profile before I ever reply for this reason ;)
  - deleted 13y ago
    [deleted]
  - deleted 13y ago
    [deleted]
  - cromwellian 13y ago
    When we released gwtquake it ran poorly on FF and the FF team seems to have spent some time optimizing for it. Imagine a press release boasting how FF optimizes for GWT. This press release is a little heavy on spin trying to market asmjs. While it does appear V8 is speeding up asmjs style code, until we know specifically about what they've done in chrome 31/32, this seems mostly like speculation. What if in fact asmjs was causing a degenerate case in their JIT and what they actually did amounted to fixing some bugs?
    - pcwalton 13y ago
      > What if in fact asmjs was causing a degenerate case in their JIT and what they actually did amounted to fixing some bugs? I don't see how that's any different from optimizing for asm.js. Optimization is often about fixing bugs.
- micro_cam 13y ago
  I ran the demo in chrome not that long after it was released and recall the frame rate being almost as good as in the recommended firefox nightly builds. There was some visual weirdness (polygons being missing/transparent). I expect Epic's announcement is more about these glitches being resolved then performance increases. Mozilla's is pure spin.
  - jlongster 13y ago
    That's not true, if you ran it in Chrome it was extremely laggy, but you must have caught it after they implemented a lot of asm.js optimizations. You can see when they focused on asm.js-style code here in these graphs: http://arewefastyet.com/#machine=11&view=breakdown&suite=asmjs-apps http://arewefastyet.com/#machine=11&view=breakdown&suite=asm.... Just look at the drop off of the green line!
    - mraleph 13y ago
      I also suggest zooming into those graphs to see which changes lead to drops (at least those that are currently visible). Then you could try to explain people what asm.js specific is in changes like: https://code.google.com/p/v8/source/detail?r=14658 https://code.google.com/p/v8/source/detail?r=14658 and https://code.google.com/p/v8/source/detail?r=15147 https://code.google.com/p/v8/source/detail?r=15147 [hint: nothing, they have more to do with how Emscripten has a tendency to produce extremely big functions which no human would write, and JIT has to accomodate for that to hit them in correct moment and not give up on them. Once it hits them however the optimizations that were there for ages, optimizations purely based on JavaScript semantics, start doing what they are intended to do --- make JavaScript run fast]
  - bad_user 13y ago
    Not sure what computer you ran the demo on, but the Unreal Engine demo on top of Chrome was unusable on my laptop (talking about 2-5 fps), whereas in Firefox it was extremely smooth and this was when Firefox 22 was released (so it was the stable release, not the nightlies). EDIT: I just ran that demo in Chrome, on the same computer as before and it did improve a lot (getting 50-60 fps in full screen HD), though it still seems smoother in Firefox. Competition is great.
fidotron 13y ago
This isn't right - the Chrome team have explicitly said they're going after general optimizations that just happen to help asm.js performance greatly, but are applied regardless of if asm.js is being used or not.
- azakai 13y ago
  What you say is true, Chrome is using a general approach to optimize asm.js code, but that does not contradict what the post says. It says that both Firefox and Chrome have optimized for asm.js, and that's correct. For example as reissbaker's comment mentions, Google even added an asm.js benchmark to Octane 2.0. That shows it is optimizing for that style of code, among many other styles of course.
  - nolok 13y ago
    That's one tortured and oriented way of looking at it. By your logic, every single dev who has ever made a js lib can make an article titled "Chrome and Opera Optimize for Whoever-Pioneered whatever.js", since the changes improve their lib. That title is making it sound like the changes were aimed at making that one case faster, when they weren't. And them adding a library to their benchmark doesn't in any way mean that they aim to optimize for it, only that they want to keep a reference on how their code perform. Just because I regularly check how my website renders in IE 6 doesn't mean I'm optimizing for it or that I consider it a target.
    - azakai 13y ago
      > That title is making it sound like the changes were aimed at making that one case faster, when they weren't. No, the changes were certainly aimed at making the case of asm.js code faster. As in the links I posted above, Google has announced they are optimizing for asm.js and that they achieved large speedups on it, they mention it very specifically, http://culturemass.com/2013/05/17/google-io-2013-keynote-part-ii/ http://culturemass.com/2013/05/17/google-io-2013-keynote-par... http://blog.chromium.org/2013/11/announcing-octane-20.html http://blog.chromium.org/2013/11/announcing-octane-20.html > And them adding a library to their benchmark doesn't in any way mean that they aim to optimize for it No, it exactly means that: Adding it to Google's main benchmark means that they consider it representative of important real-world code, and hence that optimizing for that benchmark means you are optimizing for the right stuff. As the Octane FAQ says, >> " Octane aims to be representative of actual workloads and execution profiles of real web applications. Octane's goal is to be a proxy for the JavaScript application that you'll encounter when running browser games, highly-interactive web pages or online productivity tools." https://developers.google.com/octane/faq https://developers.google.com/octane/faq
bla2 13y ago
Mozilla seems pretty desperate for asjm.js press :-/
pvnick 13y ago
Asm.js is intrinsically superior to native client (and yes, I do see them as competing technologies) and will inevitably push NaCl out of the market for one simple reason: even if the browser doesn't explicitly optimize for asm.js, the code will still run. It may not be usably fast, but something will happen. As opposed to native client, where if your user base doesn't support it you're just dead in the water. And the trend so far is javascript getting faster and closer to native running code. Google must eventually build asm.js optimizations into Chrome. What's their alternative strategy? Ignore asm.js and let Mozilla tout Firefox's javascript engine as faster? NaCl's writing is on the wall and Google knows it.
- pfraze 13y ago
  I think there's room for both to exist. The strategies are hugely different and will depend on the performance payoff, but asm.js has the simplicity to make it happen while PNaCl has the resources of Google, and since resources is what PNaCl needs (docs, dev environments, marketing) then I can see both coming to maturity. I was threatened by PNaCl for a while, until I realized that it integrates with Javascript through messaging. I think it could be a really solid complement to the Web platform.
  - jlongster 13y ago
    I'm kind of glad PNaCl is being researched, and it's really impressive engineering. I personally won't invest in it, but it will be very interesting if they pull it off, especially if other other browser get interested in it. There has been zero interest so far so I'm not betting on it. The thing that bothers me about PNaCl is the potential for Chrome to become silo'ed and for Google to start pushing it's own ecosystem over the web, if they can't get other browsers to join in. I don't think they'll actually do that, but the chance is still kind of scary.
    - threeseed 13y ago
      > I don't think they'll actually do that Problem is there is history of Google doing exactly this: SPDY.
kayoone 13y ago
Please put down these Asm.js vs PNaCl arguments. We are all going to win in the end as both ASM.JS and PNaCl run on pure Javascript (PNaCl through a pepper.js fallback and ive heared asm.js is already a PNaCl target)[1] In the end, some hugely popular cross compiled games will drive adoption of both technologies to the point where they are ubiquitous and supported by all major vendors. Apple doesnt want people saying "Wah look at how poorly Safari handles that game compared to Chrome/Firefox". [1] http://games.greggman.com/game/thoughts-on-asm-js-vs-pnacl/#comment-1140569220 http://games.greggman.com/game/thoughts-on-asm-js-vs-pnacl/#...
- CmonDev 13y ago
  But it's better to pick the one that could potentially lead to JS being phased out.
  - liviu 13y ago
    You are naive. If you don't understand JS, you can try something else that compiles to JS. There are some cool tools for people like you!
    - CmonDev 13y ago
      Transpilers are just a work-around, tooling is not mainstream yet. At the moment debugging the script is easier despite being unpleasant. I work with JS almost daily and understand it's strengths and weaknesses. I do not consider it a silver bullet which seems to be a shared sentiment around HN. A language designed to make documents more interactive should be just that. Especially if it is evolving in 5-year cycles (http://en.wikipedia.org/wiki/ECMAScript#Versions http://en.wikipedia.org/wiki/ECMAScript#Versions).
      - stelonix 13y ago
        I believe you're missing the point: with asm.js, JS isn't being used as a "silver bullet", but merely as a kind of "assembly" of web browsers. It's not that we love JS so much, it's that it's pretty much part of every browser, and as such code compiled for asm.js will run in any browser, albeit without any asm.js specific speedup if a given browser does not support it.
haberman 13y ago
It's frustrating to see incorrect information regarding NaCl in top comments. NaCl is not going to make the web x86-dependent. Recognizing the danger of an architecture-specific web, Google has disabled NaCl for everything except the Chrome Web Store. So unless you believe that the Apple App Store has been making the web ARM-specific for the last five years, Native Client is not the x86 lock-in that you may fear. And in fact, Google now recommends PNaCl over NaCl for this very reason. It recommends NaCl only in certain limited situations: https://developers.google.com/native-client/dev/nacl-and-pnacl https://developers.google.com/native-client/dev/nacl-and-pna... And even PNaCl, which requires browser support to run "normally", has a JS fallback called pepper.js. So applications targeting PNaCl do not have a hard dependency on a PNaCl runtime: http://trypepperjs.appspot.com/ http://trypepperjs.appspot.com/
- novaleaf 13y ago
  correct me if i'm wrong, but it does sound like NaCl is about "making the web x86 dependent", but google also has architecture-agnostic implementations in PNaCl and pepper.js
  - haberman 13y ago
    NaCl is disabled for the web. Chrome will not load NaCl modules from the web. [0] I don't know how I can be any more clear. [0] Except perhaps plus.google.com? I haven't heard of this before, waiting for more from pcwalton about this.
- pcwalton 13y ago
  > Recognizing the danger of an architecture-specific web, Google has disabled NaCl for everything except the Chrome Web Store. And plus.google.com. :(
  - haberman 13y ago
    Really? I hadn't heard that -- do you have a reference with more info?
ouggnay 13y ago
Is there any concrete data to support "You still get the best performance in Firefox"? I get around 26fps for 1920x1200 fullscreen on the latest Firefox nightly, but 40fps on the latest Chromium. Ubuntu precise.
- JohnTHaller 13y ago
  Comparing a pre-alpha quality nightly build is never a good way to compare real products. Comparing the current stable Chrome 31.0.1650.57 and Firefox 25.0.1 on my Windows box running at 1920x1200 yields 57.8 fps for Chrome and 81.7 fps for Firefox. Note that Firefox is pegged at a maximum of 60fps by default which will affect benchmarks. You can disable that limit with the information in the FAQ.
nashashmi 13y ago
Does this officially open the possibility of running Mozilla Firefox on a Chromebook (ChromeOS)?
- JohnTHaller 13y ago
  Nope. That will likely never be permitted.

134 points by ndesaulniers 13y ago

Is this accurate? My understanding was that the V8 team wasn't explicitly optimizing for asm.js, and just optimized V8 in general (and that often asm.js hit fast-paths even without explicit optimization). It sounds from the article like Epic announced that Chrome/V8 is fast enough to run the Unreal 3 engine, and Mozilla's trying to spin it as V8 explicitly optimized for a "spec" invented by Mozilla when actually they just made V8 really, really fast. That said, they do include an asm.js benchmark in Octane 2, so it's clearly on their radar. But as far as I've heard they haven't actually implemented special asm.js typecheckers / AOT compilers like Mozilla has.

azakai 13y ago
Not sure where you see "spec" mentioned in there? As you say, Google included asm.js code in Octane 2, and you can see progress on asm.js benchmarks as Google optimizes in ways that help that style of code on arewefastyet, http://arewefastyet.com/#machine=11&view=breakdown&suite=asmjs-ubench http://arewefastyet.com/#machine=11&view=breakdown&suite=asm... This is also not something new, Google has optimized for asm.js code since the IO keynote much earlier this year where Google reported a 2.4x speedup on an aggregate asm.js benchmark, http://culturemass.com/2013/05/17/google-io-2013-keynote-part-ii/ http://culturemass.com/2013/05/17/google-io-2013-keynote-par... There are many ways to optimize for different types of code. Firefox uses the asm.js type system for asm.js, and does AOT compilation, while Chrome chose a different approach. The two approaches have different benefits. But both browsers certainly optimize for asm.js, they both announced doing so and the numbers are proof that they are succeeding. edit: add link to Octane 2.0 and the asm.js benchmark added there, http://blog.chromium.org/2013/11/announcing-octane-20.html http://blog.chromium.org/2013/11/announcing-octane-20.html
- rictic 13y ago
  Even before asm.js there was emscripten (the primary generator of asm.js and inspiration for much of the spec), which has been used for a number of high profile demos and likely got optimization attention for years before asm.js.
  - cpeterso 13y ago
    I'm sure azakai is familiar with emscripten. ;)
    - girvo 13y ago
      This doesn't happen anywhere except on HN. I check parents profile before I ever reply for this reason ;)
- deleted 13y ago
  [deleted]
- deleted 13y ago
  [deleted]
- cromwellian 13y ago
  When we released gwtquake it ran poorly on FF and the FF team seems to have spent some time optimizing for it. Imagine a press release boasting how FF optimizes for GWT. This press release is a little heavy on spin trying to market asmjs. While it does appear V8 is speeding up asmjs style code, until we know specifically about what they've done in chrome 31/32, this seems mostly like speculation. What if in fact asmjs was causing a degenerate case in their JIT and what they actually did amounted to fixing some bugs?
  - pcwalton 13y ago
    > What if in fact asmjs was causing a degenerate case in their JIT and what they actually did amounted to fixing some bugs? I don't see how that's any different from optimizing for asm.js. Optimization is often about fixing bugs.
micro_cam 13y ago
I ran the demo in chrome not that long after it was released and recall the frame rate being almost as good as in the recommended firefox nightly builds. There was some visual weirdness (polygons being missing/transparent). I expect Epic's announcement is more about these glitches being resolved then performance increases. Mozilla's is pure spin.
- jlongster 13y ago
  That's not true, if you ran it in Chrome it was extremely laggy, but you must have caught it after they implemented a lot of asm.js optimizations. You can see when they focused on asm.js-style code here in these graphs: http://arewefastyet.com/#machine=11&view=breakdown&suite=asmjs-apps http://arewefastyet.com/#machine=11&view=breakdown&suite=asm.... Just look at the drop off of the green line!
  - mraleph 13y ago
    I also suggest zooming into those graphs to see which changes lead to drops (at least those that are currently visible). Then you could try to explain people what asm.js specific is in changes like: https://code.google.com/p/v8/source/detail?r=14658 https://code.google.com/p/v8/source/detail?r=14658 and https://code.google.com/p/v8/source/detail?r=15147 https://code.google.com/p/v8/source/detail?r=15147 [hint: nothing, they have more to do with how Emscripten has a tendency to produce extremely big functions which no human would write, and JIT has to accomodate for that to hit them in correct moment and not give up on them. Once it hits them however the optimizations that were there for ages, optimizations purely based on JavaScript semantics, start doing what they are intended to do --- make JavaScript run fast]
- bad_user 13y ago
  Not sure what computer you ran the demo on, but the Unreal Engine demo on top of Chrome was unusable on my laptop (talking about 2-5 fps), whereas in Firefox it was extremely smooth and this was when Firefox 22 was released (so it was the stable release, not the nightlies). EDIT: I just ran that demo in Chrome, on the same computer as before and it did improve a lot (getting 50-60 fps in full screen HD), though it still seems smoother in Firefox. Competition is great.

fidotron 13y ago

This isn't right - the Chrome team have explicitly said they're going after general optimizations that just happen to help asm.js performance greatly, but are applied regardless of if asm.js is being used or not.

azakai 13y ago
What you say is true, Chrome is using a general approach to optimize asm.js code, but that does not contradict what the post says. It says that both Firefox and Chrome have optimized for asm.js, and that's correct. For example as reissbaker's comment mentions, Google even added an asm.js benchmark to Octane 2.0. That shows it is optimizing for that style of code, among many other styles of course.
- nolok 13y ago
  That's one tortured and oriented way of looking at it. By your logic, every single dev who has ever made a js lib can make an article titled "Chrome and Opera Optimize for Whoever-Pioneered whatever.js", since the changes improve their lib. That title is making it sound like the changes were aimed at making that one case faster, when they weren't. And them adding a library to their benchmark doesn't in any way mean that they aim to optimize for it, only that they want to keep a reference on how their code perform. Just because I regularly check how my website renders in IE 6 doesn't mean I'm optimizing for it or that I consider it a target.
  - azakai 13y ago
    > That title is making it sound like the changes were aimed at making that one case faster, when they weren't. No, the changes were certainly aimed at making the case of asm.js code faster. As in the links I posted above, Google has announced they are optimizing for asm.js and that they achieved large speedups on it, they mention it very specifically, http://culturemass.com/2013/05/17/google-io-2013-keynote-part-ii/ http://culturemass.com/2013/05/17/google-io-2013-keynote-par... http://blog.chromium.org/2013/11/announcing-octane-20.html http://blog.chromium.org/2013/11/announcing-octane-20.html > And them adding a library to their benchmark doesn't in any way mean that they aim to optimize for it No, it exactly means that: Adding it to Google's main benchmark means that they consider it representative of important real-world code, and hence that optimizing for that benchmark means you are optimizing for the right stuff. As the Octane FAQ says, >> " Octane aims to be representative of actual workloads and execution profiles of real web applications. Octane's goal is to be a proxy for the JavaScript application that you'll encounter when running browser games, highly-interactive web pages or online productivity tools." https://developers.google.com/octane/faq https://developers.google.com/octane/faq

bla2 13y ago

Mozilla seems pretty desperate for asjm.js press :-/

pvnick 13y ago

Asm.js is intrinsically superior to native client (and yes, I do see them as competing technologies) and will inevitably push NaCl out of the market for one simple reason: even if the browser doesn't explicitly optimize for asm.js, the code will still run. It may not be usably fast, but something will happen. As opposed to native client, where if your user base doesn't support it you're just dead in the water. And the trend so far is javascript getting faster and closer to native running code. Google must eventually build asm.js optimizations into Chrome. What's their alternative strategy? Ignore asm.js and let Mozilla tout Firefox's javascript engine as faster? NaCl's writing is on the wall and Google knows it.

pfraze 13y ago
I think there's room for both to exist. The strategies are hugely different and will depend on the performance payoff, but asm.js has the simplicity to make it happen while PNaCl has the resources of Google, and since resources is what PNaCl needs (docs, dev environments, marketing) then I can see both coming to maturity. I was threatened by PNaCl for a while, until I realized that it integrates with Javascript through messaging. I think it could be a really solid complement to the Web platform.
- jlongster 13y ago
  I'm kind of glad PNaCl is being researched, and it's really impressive engineering. I personally won't invest in it, but it will be very interesting if they pull it off, especially if other other browser get interested in it. There has been zero interest so far so I'm not betting on it. The thing that bothers me about PNaCl is the potential for Chrome to become silo'ed and for Google to start pushing it's own ecosystem over the web, if they can't get other browsers to join in. I don't think they'll actually do that, but the chance is still kind of scary.
  - threeseed 13y ago
    > I don't think they'll actually do that Problem is there is history of Google doing exactly this: SPDY.

kayoone 13y ago

Please put down these Asm.js vs PNaCl arguments. We are all going to win in the end as both ASM.JS and PNaCl run on pure Javascript (PNaCl through a pepper.js fallback and ive heared asm.js is already a PNaCl target)[1] In the end, some hugely popular cross compiled games will drive adoption of both technologies to the point where they are ubiquitous and supported by all major vendors. Apple doesnt want people saying "Wah look at how poorly Safari handles that game compared to Chrome/Firefox". [1] http://games.greggman.com/game/thoughts-on-asm-js-vs-pnacl/#comment-1140569220 http://games.greggman.com/game/thoughts-on-asm-js-vs-pnacl/#...

CmonDev 13y ago
But it's better to pick the one that could potentially lead to JS being phased out.
- liviu 13y ago
  You are naive. If you don't understand JS, you can try something else that compiles to JS. There are some cool tools for people like you!
  - CmonDev 13y ago
    Transpilers are just a work-around, tooling is not mainstream yet. At the moment debugging the script is easier despite being unpleasant. I work with JS almost daily and understand it's strengths and weaknesses. I do not consider it a silver bullet which seems to be a shared sentiment around HN. A language designed to make documents more interactive should be just that. Especially if it is evolving in 5-year cycles (http://en.wikipedia.org/wiki/ECMAScript#Versions http://en.wikipedia.org/wiki/ECMAScript#Versions).
    - stelonix 13y ago
      I believe you're missing the point: with asm.js, JS isn't being used as a "silver bullet", but merely as a kind of "assembly" of web browsers. It's not that we love JS so much, it's that it's pretty much part of every browser, and as such code compiled for asm.js will run in any browser, albeit without any asm.js specific speedup if a given browser does not support it.

haberman 13y ago

It's frustrating to see incorrect information regarding NaCl in top comments. NaCl is not going to make the web x86-dependent. Recognizing the danger of an architecture-specific web, Google has disabled NaCl for everything except the Chrome Web Store. So unless you believe that the Apple App Store has been making the web ARM-specific for the last five years, Native Client is not the x86 lock-in that you may fear. And in fact, Google now recommends PNaCl over NaCl for this very reason. It recommends NaCl only in certain limited situations: https://developers.google.com/native-client/dev/nacl-and-pnacl https://developers.google.com/native-client/dev/nacl-and-pna... And even PNaCl, which requires browser support to run "normally", has a JS fallback called pepper.js. So applications targeting PNaCl do not have a hard dependency on a PNaCl runtime: http://trypepperjs.appspot.com/ http://trypepperjs.appspot.com/

novaleaf 13y ago
correct me if i'm wrong, but it does sound like NaCl is about "making the web x86 dependent", but google also has architecture-agnostic implementations in PNaCl and pepper.js
- haberman 13y ago
  NaCl is disabled for the web. Chrome will not load NaCl modules from the web. [0] I don't know how I can be any more clear. [0] Except perhaps plus.google.com? I haven't heard of this before, waiting for more from pcwalton about this.
pcwalton 13y ago
> Recognizing the danger of an architecture-specific web, Google has disabled NaCl for everything except the Chrome Web Store. And plus.google.com. :(
- haberman 13y ago
  Really? I hadn't heard that -- do you have a reference with more info?

ouggnay 13y ago

Is there any concrete data to support "You still get the best performance in Firefox"? I get around 26fps for 1920x1200 fullscreen on the latest Firefox nightly, but 40fps on the latest Chromium. Ubuntu precise.

JohnTHaller 13y ago
Comparing a pre-alpha quality nightly build is never a good way to compare real products. Comparing the current stable Chrome 31.0.1650.57 and Firefox 25.0.1 on my Windows box running at 1920x1200 yields 57.8 fps for Chrome and 81.7 fps for Firefox. Note that Firefox is pegged at a maximum of 60fps by default which will affect benchmarks. You can disable that limit with the information in the FAQ.

nashashmi 13y ago

Does this officially open the possibility of running Mozilla Firefox on a Chromebook (ChromeOS)?

JohnTHaller 13y ago
Nope. That will likely never be permitted.