I was asked to give a presentation on the recent developments in Firefox Mobile for the Mozilla Vision 2012 conference in Tokyo. It gave me a chance to reflect a bit on what we did, why we did it and how things are going. The “what” in this case is rewriting the UI for Firefox Mobile using native Android widgets. The “why” can be summed up in the following goals:

Faster start-up time

Support for Flash

Use less memory

We have been fairly “heads down” working on native Firefox for Android over the last 3 months. Re-writes are scary. It’s a race to re-implement existing functionality while adding all new bugs. We are finally to the point in the project where things are settling down. We are focused on stability issues, getting ready to release the native version to a larger audience. As for the primary goals, we have good news:

Start-up time is many times faster than the XUL version. Launching via the icon is almost instantaneous.

Flash is supported on Froyo and Gingerbread. We need to reverse engineer the changes made for Honeycomb and ICS. There is no documentation for this work.

With a single-process, we have reduced memory quite a bit. We still can get killed in the background by Android – it’s supposed to do this – but when this happens, we start up very quickly and restore your session.

We still support add-ons using the native UI!

I’m looking forward to being able to move forward again, designing/implementing new features on a solid foundation. We have plenty of new experiments and projects waiting to move forward.

Mozilla Vision 2012 was a great conference and very well attended. I’m very glad I had the chance to participate. Here is the link to my Google Docs presentation. It has a bit more details.

The new native Android UI version of Firefox does not ship with a dedicated Error Console. Instead, all console messages are redirected to the Android system log – also known as logcat. If you have the Android SDK installed, you already have a way to view the logcat:

We have been talking a lot recently about the new native UI version of Firefox for Android. Built using native Android UI widgets, packed with major speed improvements and large memory reductions. We have not been working on the project very long, but we have been making solid progress. We decided it’s time to move the native builds into our nightly delivery channel.

The nightly channel is a snapshot of our very latest development work, before it is ready for widespread testing. This is our least stable update channel, and is not recommended for most users. Nightly will offer to update itself automatically, once a day, with the latest changes. If you have a nightly Firefox installed on your Android device, when it updates on November 23rd, you’ll be running the new native UI build.

The XUL-based version of Firefox had several years of development and the nightly builds have a relatively high level of stability. The new native UI builds are not that mature and you will find some OMGWTFBBQ flaws. We have a quick summary of known issues on the Nightly download page. I’ll call out a few of the big ones here:

Sync is not supported yet: Sync is also being refactored for the move to native and isn’t ready yet.

Panning and zooming have issues: Pages layout too wide for phones and zooming results in fuzzy content. These are our highest priority items and we are landing improvements everyday.

Tablet UI is not ready: We are focused on phones and the tablet UI has not caught up. Tablet UI is not a high priority for the native UI project since we can fallback to shipping the XUL-based version on tablets until we have a solid native tablet UI.

Bookmarks and History are saved to the system storage: We save bookmarks and history in the same storage that the stock Android browser uses. It provides tighter integration, but does mean the data is not locked away in a Firefox-only location. Passwords and other data are stored in a Firefox-only location.

If any of these issues make you uncomfortable or you are worried about the changes in stability, we urge you to move to the more stable Aurora channel. The Aurora channel is still the XUL-based Firefox you have been using.

We certainly hope you give the new nightly a chance and help us improve the quality and stability by filing bugs.

Note: If you have been using the native UI builds, especially on a tablet, we recommend uninstalling and re-installing the current nightly.

Firefox for Android, both the XUL and Native versions, currently requires an ARMv7 CPU. We are looking into adding support for ARMv6, but the ARMv7 limitation had one painful drawback: We could not run Firefox on the Android emulator since it only supported ARMv6.

This is no longer true! The latest version of the Android SDK ships with ARMv7 images for the emulator.

Christian Holler (decoder on IRC) was kind enough to make a wiki page with instructions on setting up the emulator with ARMv7 support. As Christian points out, Firefox does not run at top speed in the emulator, but it’s a heck of a lot better than no “desktop” options at all. Oh yeah, the new native Android UI builds have no desktop counterparts, so the emulator is the only way to run those builds on a desktop machine.

One of the first things I yelled about when we were debating switching to a native Android UI for Firefox was add-on support. Using a XUL-based UI meant add-ons were free. The Mozilla platform has support for add-ons baked right in. Moving to a native UI would surely kill our ability to support add-ons, right? Wrong!

Add-ons are an important part of the Firefox story. Native UI builds of Firefox support add-ons. There are some things an add-on developer needs to be aware:

The add-ons system is the same one used in other Mozilla applications. We did not invent a new add-on system.

Native UI builds are considered a new application and are not add-on compatible with the XUL versions. The application ID for native UI builds is: {aa3c5121-dab2-40e2-81ca-7ea25febc110}

There is no visible XUL in the UI, so using overlays to try to add or change UI is useless.

There is a simple NativeWindow object that allows you to manipulate parts of the native Android UI.

Services like nsIPromptService and nsIAlertsService are implemented to use native Android UI.

Since overlays are useless for UI and JavaScript APIs are available for native UI, you should seriously consider just making a restartless add-on.

NativeWindow

We wanted to give add-on developers some APIs to manipulate the native Android UI, so we create a helper object called NativeWindow. The API is still young, but it gives you access to: Android Menu, Doorhanger Notifications, Context Menus (in web content) and Android popup toast alerts. The object is currently part of the main browser window, but we are considering moving it to a JS module. The basic API is here:

/*
label: menu label
icon: file:// or data: URI for an icon
callback: JS function called when menu is tapped
returns a menu ID that can be used to remove the menu
*/
menuID = NativeWindow.menu.add(label, icon, callback);
NativeWindow.menu.remove(menuID);
/*
message: displayed text
value: string based tag
buttons: array of JS objects used to create buttons in the notification
tabID: tab associated with this notification
options: JS object that has 'persistence' and 'timeout' options
*/
NativeWindow.doorhanger.show(message, value, buttons, tabID, options);
NativeWindow.doorhanger.hide(value, tabID);
/*
label: menu label
selector: JS object that has a 'matches(element)' function. Used to show the menu.
callback: JS function called when menu is tapped
returns a menu ID that can be used to remove the menu
*/
menuID = NativeWindow.contextmenu.add(label, selector, callback);
NativeWindow.contextmenu.add(menuID);
/*
message: displayed text
duration: "short" or "long"; Used for alert timeout
*/
NativeWindow.toast.show(message, duration);

Some examples of what the API can do:

Doorhanger Notification

Menu Item

Context Menu Item

Toast Popup Alert

The NativeWindow API will continue to grow and mature, but I think even now it shows that add-ons can have first-class interactions with the native UI of Firefox. I am looking forward to developers trying it out and helping us push the API forward.

You have probably seen some announcements and read some blog posts about Mozilla’s recent change in direction for Firefox Mobile on Android. We have decided to drop the XUL-based UI and re-build the application using native Android widgets. Here’s some of the rationale, from Johnathan’s newsgroup post:

Startup – A native UI can be presented much faster than a XUL based UI, since it can happen in parallel with Gecko startup. This means startup times in fractions of a second, versus several seconds for a XUL UI on some phones.

Memory Use – We believe a native UI will use significantly less memory.

Responsiveness – A native UI has the potential for beautiful panning and zooming performance.

Another major change is a move away from multi-process architecture (e10s) as well. The web content process was great for stabiilty, keeping crashes from taking down the entire application, but it also increased our memory usage and created some performance issues. In the new application, Gecko is running in a separate thread, not a separate process.

Quite simply everything you see is a native Android widget. Even the web content is displayed in a native view, very similar to the multi-process layers system we previously used. This allows us to asynchronously pan and zoom the web content, without waiting for the browser to scroll or zoom the actual content.

Even though the UI is completely implemented in native widgets, there is still a lot of JavaScript around, it’s just not visible. JavaScript is the perfect binding language into the Gecko platform and we are still using it for many of the same tasks. If you have ever built a browser using XUL, take a look at the browser,js file and you will see some familiar code. Because we have such a strong JavaScript binding layer, we can support add-ons in much the same way as a XUL-based application. More on that in a future blog post.

A few more details on how these three systems interact can be found in this basic architecture document. There is some details on the simple messaging system we use to allow the JavaScript and Java systems to communicate too.

The current nightlies are very usable, and support Flash (yes they do!) – so go grab the APK and try it out yourself.

Firefox Mobile recently hooked up the same performance data telemetrysystem used by desktop Firefox. If you use the Nightly version of Firefox Mobile, you can start sending anonymous performance data back to Mozilla. We will use this data to improve future versions of Firefox Mobile.

It’s really easy to use and is completely anonymous. Once you enable the feature, everything happens in the background. To enable, go to the Feedback panel and make sure Send performance data is toggled on.

Lots of discussiongoing on recently about the affect of 6 week development cycles on binary XPCOM components in add-ons. I don’t want to re-hash those discussions, but Daniel Glazman brought up an interesting point in a comment on Wladimir’s post. Wladimir was suggesting binary component developers start moving to js-ctypes. Daniel pointed out that there are two classes of binary XPCOM components:

XPCOM wrappers around 3rd-party binary libraries: We use this model for exposing external binary functionality into JavaScript so add-ons and applications can access the libraries. Using js-ctypes should provide a simple, non-breaking way to expose the libraries. You create a simple JavaScript wrapper in a JavaScript XPCOM component. We need more examples of using js-ctypes to do this, but it works.

Pure binary XPCOM components built only using the Mozilla platform: Sometimes the functionality you want to expose is actually locked away in the Mozilla platform itself. Maybe there is no public nsIXxx interface or the existing interface has a [noscript] attribute on a property of method. This model shouldn’t be required anymore, in my opinion. Mozilla is pushing JavaScript based components and we should be exposing as much as possible to chrome JavaScript. I would encourage add-on developers to file bugs and lobby to expose binary-only parts of the Mozilla platform to chrome JavaScript.

JavaScript ctypes has come a long, long way since it was started back in 2007. Let’s start leveraging it more. The ctypes model has been used quite effectively in other languages.

Text selection in web content: Long tap in a web page and start selection text using the familiar Android-style drag handles. Since Firefox does not use Android widgets, we had to implement this feature ourselves and there is still some additional work to do in order to make it more robust.

Session history within a tab is saved and restored: If Firefox needs to restore the session, each tab’s back/forward history is restored as well.

Language selection at initial startup: Choose you language right away, instead of wading through screens in a language you might not be able to read. If the Android OS is set to a language Firefox has bundled, the selection screen is skipped and you are taken to the Firefox Home page. If you really wanted to pick a different language, there is a “Choose Language” button on Firefox Home too, but only on the initial startup.

Added a ‘Quit’ action to the Android menu: This was a frequent feature request and low risk to the UI so we added it.

Text selection in action:

Quit menu:

Of course, Mobile Aurora 7 also has the features and optimizations found in the upcoming Firefox for Mobile 6 Beta release. Things like startup and painting speedups, Gingerbread theme, Android menu improvements and more. We’ll post more details about Firefox for Mobile 6 Beta soon.

Mobile Aurora 7 is not in the Android Market. We are considering publishing it along with the Beta and Final releases. Until then, install the latest Mobile Aurora from this download page.

A long time ago, in May 2008, I posted about a remote JS shell add-on I was building. I had been tinkering with a few existing projects (JSSH, SD Connect and MozRepl) but wanted to build something small, lightweight and mainly focused on helping add-on / XUL developers interact with JS running in a separate application. I tried to get the protocol closer to that used by Opera DragonFly and Crossfire, but I never had the time to get it exactly right. When I started work on Firefox Mobile, I used the add-on to interact with Firefox running on a mobile device from my desktop machine. Unfortunately, I never felt the UI and the code were good enough for a public release.

Recently, I dusted off the code, converted to restartless add-ons and made a very simple in-content UI. I say add-ons, because there are two: a probe, and a shell. You install the probe into Firefox Mobile and install the shell into Firefox Desktop (or Firefox Mobile running on a desktop – it’s up to you).

Shell

The shell is implemented as an in-content about: page [1]. After installing the shell, navigate to “about:firefly” and you’ll see the simple UI. The shell can act as a listening server or you can connect to a relay server. The listening server is simplest, so start with that.. You start the server on a specific TCP port. Once started, the shell waits for a probe to connect.

Probe

The probe is simple. After installing it, you just point it at an instance of the shell by entering the IP address and port. You can connect and disconnect from the “Remote Debugging” preferences. That’s all you need to do with the probe.

Starting a Session

Once the probe has connected to a shell, you can enter JavaScript commands into the simplistic shell UI, the code is sent to the probe and evaluated in a sandbox running in the application. Because it’s a sandbox, the probe injects some helper properties and methods:

window – The active chrome window. With this object, you have full access to the window’s JS and DOM.

firefly – Injected API with some special utility methods:

getWindow(type) – Returns the chrome window of a given type.

getWindows() – Returns an array of all open windows.

inspectJS(object) – Lists all properties and functions associated with a given JS object.

inspectDOM(selector or element) – Dumps the markup for a given DOM element. You can pass a CSS selector string or a real DOM element to the method.

Examples

Since we are talking about Firefox Mobile, you should be familiar with the internal chrome UI code before starting to poke around. The main browser.js has a Browser object that acts like a manager for the open tabs, so let’s play with it:

Add access to the web content running in the child process. Firefox Mobile is multi-process, so you can’t directly access the web content from the main process.

Add a pretty output for the inspectXXX helpers. Instead of just dumping the simple text output into the HTML, we could make the output more dynamic – think Firebug panels.

Add helpers to do more profiling and data collection. Many times I want to know what is happening on the device. Things like CPU and memory usage or why the profile data is exploding.

Bug reports and feature requests welcome.

[1] Yep, an about: page in a restartless add-on. It wasn’t too hard. I am using a resource: alias for the external CSS file and the favicon. I could have just move the CSS into the XHTML file and used a data: URI for the favicon.