Firefox is one of the largest open source project on the net. There are roughly 350MM users that depend on Firefox, and we have roughly 3,000 patches per release, from 400 unique monthly contributors on mozilla-central alone.
Given our reach and the maturity of our project, we have to be very careful of what we deploy to users' devices. Most developers nowadays are used to writing web applications, server and client-side.
The ergonomics of developing for the web are a departure from "desktop-software" and highly contrast with developing a browser:
Given the high stakes and the high impact, we adopt fairly rigorous quality standards and processes. Unfortunately, that can also slow us down from a product development perspective and adds a long latency between conception and delivery. New ideas are extremely costly, so are mistakes.
Many of us want to go faster, to try new ideas and delight users. In fact, we could even say that we need to do so to stay relevant. I'd like to propose a new way to do Firefox engineering: to remotely-host UIs in Firefox.
Firefox is a web browser, and it may seem paradoxical, but we've only recently started using current web technologies for our own UIs. The web, until recently, wasn't ready for a desktop-class application. We think that has changed today. With HTML5, CSS3 and newer web APIs like ServiceWorker and more, we think we can deliver a UI experience on-par with what we make with XUL.
One of the benefits of using modern web technologies is that we can host our UIs on servers, and update them just as we would normal web pages. This opens the door to many workflows that seem routine to developers accustomed to deploying server-side applications:
Users expect a high-quality experience using Firefox and we have many users. This is one of the reason of why our process is rigorous to begin with.
However, it doesn't make sense to have the same kind of scrutiny on presentation code than on platform code. For instance, should we choose to use a red button vs a grey button, it should not take 3 months+ to ship. This makes any product change extremely onerous. This also lowers the quality of the experience we can deliver to our users, because we take a lot of time to try out new things.
A page failing to load due to a Javascript error, for instance, won't break Firefox in a web page. However, as "browser chrome" code, that's a very real possibility.
Quickly update-able UIs can be easily isolated and errors contained. The idea is to make Firefox use regular web pages for "browser chrome", similar to another Mozilla project: browser.html.
Users' expectation of the web is not what it was before. More of the browser's capabilities require external services. Accepting remote data and code has serious security implications. Pages that come to mind are about:home, which load remote Javascript, about:healthreport, about:accounts and more.
Currently in Firefox, user interfaces run code that have system privileges (a.k.a. chrome privileges). This means that the code that runs Firefox UIs can do what the Firefox application can generally do; i.e. read/write files off disk, execute code on the users' computer, etc.
On the server-side, we use server and network providers we trust, but they could get compromised and leave our users exposed.
Being a high-value target, using web technologies is a great, because it does what we're trying to prevent: access to more of what is needed.
We're proud to say that we're trying this new engineering strategy on the new tab page. It is a very visible piece of browser real estate and would demonstrate at scale how this method works out.