Mozilla’s plans for Firefox: More partnerships, better add-ons, and faster updates

Mozilla is reexamining and revamping the way it builds, communicates, and decides features for its browser. In short, big changes are coming to Firefox.

Mozilla doesn’t break out the exact numbers for Firefox, though the company does say “half a billion people around the world” use the browser. But Firefox has been bleeding market share for months, and something has to be done.

The news comes after a private event Mozilla held in Whistler, Canada last week. The company published a blog post titled “What to Look Forward to from Firefox” soon after, outlining the three pillars (focus areas) for its strategy when building its browser: uncompromised quality, best of the Web, and uniquely Firefox.

But the blog post didn’t really say anything new (hence why it didn’t get much coverage). Mozilla outlined some of what it has done over the last few years, unsurprisingly recommitted to making Firefox better, and noted the browser would soon be launching on iOS and Windows 10.

Today, Dave Camp, Firefox’s director of engineering, sent out two lengthy emails, just three minutes apart, to the Firefox Dev mailing list: Three Pillars and Revisiting how we build Firefox. Both offer a lot more detail into what Mozilla is hoping to achieve.

Uncompromised quality

First off, Mozilla has a new program called “Great or Dead.” As the name implies, Firefox will be going through some pruning: “Every feature in the browser should be polished, functional, and a joy to use. Where we can’t get it to that state, we shouldn’t do it at all.”

Mozilla says that leads to three options for each feature: spending more time to improve it, simply removing it, or “finding third-party services or add-ons that can do the job better than we can.” Firefox die-hard fans likely won’t like the sound of the last one.

Mozilla recently integrated Pocket into Firefox. Many Firefox users criticized the move, forcing the company to explain its decision.

The Firefox team will be putting together “a list of the features that need this sort of review.” Then it will ask for help maintaining that list, reviewing the features, and “getting them where they need to be.” Furthermore, Mozilla will be reorganizing its resources to pull this off: “Expect to see some of the effort spent on new feature development shift to bringing existing features up to our standards.”

Right now, we only know of one feature on this list: Electrolysis, the project that aims to bring multi-process support to Firefox. Electrolysis has been a very long time coming; the company started making it possible for the front-end and add-ons to support multiple processes back in early 2013.

Best of the Web

This pillar ties into Mozilla’s reliance on its add-ons community and partners. The company is now saying it wants to lean on them more for browser features that can’t be built in-house. Here Mozilla once again addressed the criticism surrounding the recent Pocket integration.

One of the main complaints was that Pocket should have been included in Firefox as a bundled add-on, making it very easy to remove completely from the browser. Mozilla has finally admitted its fans are right: “We tend to agree with that, and fixing that for Pocket and any future partner integrations is one concrete piece of engineering work we need to get done.”

Mozilla also noted that the Pocket integration was promoted on Firefox’s main screen, which “may not be a scalable solution.” Indeed, if the company wants to work closer with more partners, it needs to figure out the best way for Firefox to surface these additions.

This renewed focus on partnerships doesn’t mean add-ons will be getting less attention. Apparently, the opposite is true: “We intend to spend some significant effort making add-ons even more awesome by improving security and performance for users and a building a better API that increases x-platform compatibility for add-on authors and partners.”

Uniquely Firefox

This is the part where Mozilla revealed a little more on what to expect in terms of new features. “Work is going to largely be focused on the reasons users choose us in the first place.”

According to the company, that means features that help users shape and control their experience on the Web, including an improved Private Browsing mode. In short, personalization and online privacy will be the name of the game.

Mozilla also dropped a hint: “We sometimes talk about putting the Agent back in User Agent. It should filter the Web on our behalf, with our guidance.”

The user agent allows websites to know what features a visiting browser supports, and serve up different content as a result. Mozilla might be interested in telling websites that they should treat Firefox users differently, though what exactly that might entail is anyone’s guess.

On Firefox for Android at least, at least one idea has already been shared. Mozilla web compatibility engineer Mike Taylor has explained that as of Firefox 41, the default user agent string will contain the Android version in the platform token. For interoperability purposes, if a user is on a version of Android lower than 4 (which Firefox still supports), the user agent will report the Android version as 4.4.

Development

All of the above was from the first email. The second one is about the “go faster” project, which addresses Mozilla’s browser deployment strategy.

Mozilla wants to change how Firefox is built. Just like Chrome, most Firefox code is currently in development for about 18 weeks, and users get a new version every six weeks or so.

The company wants to cut that down: “We think there are big wins to be had in shortening the time that new features reach users. Critical fixes should ship to users in minutes, not days.”

Mozilla also wants to drop XUL and XBL. Both markup languages are used to build Firefox and its features, but the company is now interested in using the same technologies that developers use to build Web content.

The explanation is quite simple. XUL and XBL are outdated: “Because XUL and XBL aren’t web technologies, they don’t get the same platform attention that HTML does (for good reason!). Performance problems go unfixed and it creates a lot of unnecessary complexity within Gecko. It’s harder for even experienced web developers to get up to speed. It’s further from the Web, and that doesn’t help anybody.”

This would eliminate the need to support XUL and XBL in Gecko, Firefox’s rendering engine, and would make it easier for anyone to contribute to the Firefox project (as learning XUL and XBL would no longer be required). XUL and XBL are essentially Mozilla-specific languages, and thus obviously much less widely known than Web technologies.

That said, Mozilla isn’t yet sure what technologies to adopt instead, how this will affect add-on developers, and how much time to dedicate to this departure. As always, the company is looking to its community for help.

Indeed, this is a common thread in both emails: Mozilla has many, many ideas but it hasn’t yet decided how to execute them. Firefox’s future naturally depends on not just what, but how well Mozilla executes its plans for Firefox.