[Interview] Johnathan Nightingale, Director of Firefox Engineering

Firefox has been a popular browser with the developer community. Johnathan Nightingale, Director of Firefox Engineering, Mozilla, shares his insight on the rapid developments in the browser space, UI, and Flash support on mobiles.

While Native UI is a good idea for Android, would it not limit the portability of Firefox to other mobile devices / platforms? And if it is individually ported to each platform, would not the add-ons API be different for each platform?

It may actually help portability. The performance, responsiveness, and memory benefits of building a native UI on Android are massive and that is likely to be true on other mobile platforms as well. The work we’re doing now on Android is forcing us to build a very clear separation between the UI and the underlying logic, more than we’d need to do for a gecko/XUL based UI. If we were to target other platforms in the future, the work we’re doing here is likely to make it much simpler to use their native features as well.

Add-ons on mobile don’t tend to have much of a UI, if any, so the impact of this change is likely to be minimal. We will provide consistent jetpack APIs for things like adding a menu item, but most add-ons on mobile are interacting with content or with browser fundamentals, not with the user interface itself, and those APIs are completely consistent.

How will the move to a native UI on Android affect the tablet version of the browser that was in development?
Right now the engineering team is focused exclusively on the phone-based browser, but our designers are certainly working with both in mind. If you do have an Android tablet, though, you should check out Firefox Beta in the app store, which has the updated UI you mention. I think it’s gorgeous.

While we appreciate that lack of NIH syndrome at Mozilla, why was Orion selected over your own Ace for the Firefox scratchpad?
Orion was the right tool for the job. We have a lot of love for both projects, but for the constraints we were working with, Orion made sense.

Firefox is adding many developer-centric features in upcoming releases. Would these not be better served as add-ons for those who actually want to do web development?
A lot of web developers take their first baby steps into web development through View Source. Having tools built in to the browser that help the curious understand how the web works, and realise that they can be part of building it, is important to us. There is a vast ecosystem of incredible Firefox add-ons built for web developers, and we’re really proud of that. We want the work we do in the browser to complement and support the other tools we see out there.

There was a prototype long back of a new way of delivering Firefox features, where one could opt-in to new features – which would install the relevant addons we presume – has that approach been abandoned with the quicker release cycles?
We’re always experimenting with ways to deliver features to our users faster, or to get early testing on new ideas. These days, one of the best ways to get access to features early is to run the Firefox Aurora channel, which is 12 weeks ahead of release. You can also install the Mozilla labs test pilot add-on to see new prototype features and, with your approval, help us gather data about browser usage to inform future designs.

There was also an overhaul of the UI planned. If that is still planned, how does that work with the new release cycle? Long term projects can still happen in a separate branch, but considering that any features added to Firefox in the duration will also need to be ported to the new UI.
Our new release cycle makes this much easier. You’re right that large projects can happen in a separate branch, but for something like this we also have the ability to break it down and deliver updates incrementally. This reduces confusion for our users because their browser evolves gradually and intelligently instead of suddenly looking completely different, and it also reduces the porting stresses you mention around new features. You can see evidence of this already, with the introduction of domain highlighting in the URL bar and, if you’re on our early-access Aurora channel, the forward button that hides itself when not needed.

What about electrolysis? Is there a time-frame in place for that?
Electrolysis was a long-term project to get us better UI responsiveness through separation of content and chrome processes, but right now we’re focused on a set of near term responsiveness improvements instead. Working on responsiveness incrementally, lets us get improvements to users more quickly, and saves our add-on community the compatibility issues that electrolysis would represent.

Support for Flash on Android is just now landing, just as Flash for Mobile has been EOL’d, is there a chance this feature will be backed out?
Mobile users on the web today want Flash support, regardless of any EOL announcements, so you won’t see us backing away from that work in the near term.

Most of the objections against WebP are no longer valid, is it now being reconsidered for inclusion in Firefox?
New formats always have a hard challenge – they need to be better than the existing formats by a wide enough margin to justify the engineering cost to build and support them. It’s great to see WebP improving and responding to feedback. Our engineers have ongoing discussions with the WebP team, but it’s not on the roadmap for inclusion yet.

The concept of sending a working tab to a another device is wonderful, however often he mobile and desktop versions of the site are very different, and will sharing the session still be possible?
The web is still learning what it really means to be mobile, and so questions like this are things we’ll all figure out the answers to in the coming months and years. In Firefox, tools like Sync make it amazingly easy to move from desktop to mobile and keep all the knowledge your browser has about your bookmarks, history and saved passwords. There’s definitely more work to do, though, for browsers and site authors.

If Google integrates Dart into Google Chrome, will Mozilla be willing to embrace it too?
We are not currently considering support for Dart as a programming language in Firefox.