Firefox Quantum considers arm devices second class citizens
Everyone loves the Firefox 57 (Quantum) update which made Firefox feel like a contender again, but on the hardware where that speed increase would really be a great benefit - low end arm devices like the raspberry pi or in crouton on arm based chromebooks - it won't run. In fact, Firefox version 55+ hasn't worked on this architecture since earlier this year (2017).
Something changed after version 52 and Firefox will just instantly crash when launched. I only noticed in September when I got around to updating my Xenial (Ubuntu 16) based crouton install which is running on an ASUS C201 (Rockchip powered 11.6" chromebook) and got Firefox 55. It had been awhile since I'd updated so I didn't realize there was a problem in August when 55 first came out. I ended up having to dig through the available builds on Canonical's Launchpad until I found one that would run. The last one that works for me is 52.0.2. I was able to install that manually (with
dpkg -i) and then hold off future automatic upgrades (with
apt-mark hold firefox).
update: a new build for trusty seems to be working on xenial!
I found the problem had already been reported on Launchpad but the bug appears to be somewhere upstream (Mozilla Firefox) and had already been reported there as well. I signed on to the Launchpad bug to offer my info (and be notified) but I was disheartened to learn that Mozilla apparently doesn't commit any resources to arm development at all. They classify arm as a Tier 3 architecture which means they depend on the distributions to submit patches to them. That means we'll have to wait for Canonical to submit a patch for it to Mozilla, but Xenial is already old so unless they backport a fix from their latest distribution (which is Artful at this time) I'll just have to stay on 52. Another option might be to upgrade crouton to Artful when Firefox Quantum is fixed and running on arm under that distro but at this time for crouton Artful is still listed as "unsupported, but may work with some effort" and the most recent posts on the bug report suggest it still isn't fixed for Artful anyway. For various reasons I need Firefox to work in crouton so I'm glad I have a workaround, but Firefox Quantum would be really nice on this slow hardware.
A last, and possibly more compelling fix might be to upgrade to a faster chromebook running on an Intel chip and so avoid the arm problem entirely. The ASUS C202SA-YS-02 is a really nice and ruggedized version of the chromebook I currently use. Designed for educational use it can take a beating and its certified for use with the Google Play store out of the box so I wouldn't have to muck with the stupid script everytime there's a ChromeOS update to re-enable it.
update 180313: while I have removed all past comments, this story is still fresh enough that I thought it was worth including them.
On on 2018-01-15 20:25:50 Chris Worsley wrote:
see posts #37-40 on the launchpad.net thread you linked in your blog post. Looks like they now have something workable from Trusty onwards. Nice blog btw. I enjoyed reading about what you've done with your C201 - I hadn't realised Play could be enabled by Crosh command, so have been trying that out too on mine. I have Debian SID via crouton on mine & have reverted to Firefox ESR, so now might try that solution in post #40.
I replied on 2018-01-17 11:43:46
I updated to the latest build: 57.0.4+build1-0ubuntu0.16.04.1 and made the manual change in prefs.js to add the line:
but still crashed on startup so I've reverted back to 52.0.2 It does sound like they're getting close to a solution though. Also, I do see now that the last poster got it working with the version for 14.04.1 but I'm running my crouton with xenial (16)
and I followed up again just a bit later 2018-01-17 12:01:52 with:
Once I realized that the solution required the version built for trusty I went back and installed that. I skipped the user preference edit just to see what would happen and it started up fine! I'm using it to write this post. Thanks!