Author: Mark Finkle

Posted on

Firefox for Mobile: What’s New in Mobile Aurora 7?

The latest Firefox Mobile Aurora 7 release has many of the same great features as Firefox Desktop Aurora 7. The new memory optimizations make running Firefox on Android much more pleasant, with fewer browser session restarts.

There are also a few mobile specific changes:

  • 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.

Posted on

Firefly – Remote JS Shell for Firefox Mobile

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:

URL of active tab:
window.Browser.selectedBrowser.currentURI.spec

Add a new tab:
window.Browser.addTab("http://mozilla.org", true)

Inspect the active tab JS object:
firefly.inspectJS(window.Browser.selectedTab)

If you’re interested in using Firefly, you can install the add-ons from here:
Shell: firefly-shell
Probe: firefly-probe (mobile shortcut: http://bit.ly/irvpjc)

Source code:
Shell
Probe

Next Steps

  • 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.

Posted on

Firefox for Mobile: Channels and Branding

I mentioned that Firefox for Mobile (codenamed Fennec) has adopted the same rapid release system as used for development of desktop Firefox. The new system creates four (4) channels, each with possible releases: Nightly, Aurora, Beta and Final. With Fennec, you can have all four channels installed on your device at the same time. The installs do not share any files or data – they are completely isolated from each other.

Fennec has adopted new branding for releases. First up is the Nightly channel. As with desktop Firefox, the Nightly channel is our bleeding edge and the new branding has landed there first. If you install or update and existing nightly release of Fennec, you’ll see the new logos and naming. Don’t be alarmed – it’s the same Fennec you know and love, just with a new name and logo.

The branding consistency with desktop Firefox will also trickle into our Aurora channel soon. Firefox for Mobile beta branding will deviate slightly from desktop Firefox. The logos and title will contain “Beta” text to avoid confusion when both final releases and beta releases are installed on the same device.

Posted on

Firefox for Mobile: Rapid Release Process

By now you are probably aware that desktop Firefox has moved to a rapid release system, utilizing several new code repositories and a focused strategy for creating releases in a timely manner.

Like desktop Firefox and Thunderbird, mobile Firefox has decided to adopt the same schedule-driven release plan. Currently, mobile is building “Fennec 6.0a1” nightly builds from mozilla-central. We plan to create an Aurora branding and start creating “Fennec Aurora 5.0a2” nightly builds from mozilla-aurora. While desktop Firefox is looking to create a significant user base on Aurora, Mobile is not actively promoting Aurora, since our user base is smaller and we’d like to focus user testing on the nightly release. We will re-evaluate this position as our user base grows.

Since we are sticking to the same release schedule as desktop Firefox, we will be releasing a mobile “Firefox 5 Beta 1” on or around May 17th. Normally, we would be building the beta from mozilla-beta, but we hit a snag for this cycle and will be using a one-time only fallback repository. In order to make sure things go smoothly, we’ll do a pre-beta build sometime next week, ahead of the official beta.

The plan is to put the beta releases in the Android Market. The beta releases will install alongside the final releases, but will have beta-specific branding, to minimize confusion with the final releases. Desktop Firefox has a channel-switcher, allowing users to easily move between Aurora and Beta channels. Mobile has no plans to create a switcher. Each release has it’s own profile and run separate from any other installed releases.

Posted on

Zippity Update – Telemetry

I updated Zippity, our crowd sourcing data collection system, to add support for memory and CPU data telemetry. What is memory and CPU data telemetry you ask? Basically, we send data about the current Firefox Mobile memory and CPU usage patterns to Zippity. There are two ways to send the data:

  • Manually push a button: This might be a handy way to report metrics when you think Firefox Mobile is running slow on your phone.
  • Silently on idle once a day: During an idle moment, Zippity scans the metrics. This gives us data on the Firefox Mobile resting state. Hopefully we don’t see large CPU usage. Just install the Zippity add-on, and you start sending data – no additional work for you!

Why send this data you ask? We care a lot of the performance of Firefox Mobile, and we want to better understand how Firefox Mobile is running on your phone. We run a lot of tests at Mozilla, but these tests sometimes don’t compare well to the real world. For example, I have no performance issues running Firefox Mobile on my Nexus One, but we get lots of feedback from users that the performance is too slow on their phones. We need to run tests and collect data from Firefox Mobile running on your phone.

What kind of data is sent you ask? Firefox Mobile has a built-in memory reporting system and Zippity will enumerate that system to get detailed memory usage data. We also use the Linux /proc system to get information about the CPU usage. We only check the Firefox main and child processes. We don’t log any information about other processes. Thanks to Brad Lassey and Taras Glek for helping me get the data collected. Here is an example of the JSON formatted data sent to Zippity:

{
    "product": "Fennec 6.0a1",
    "os": "Android",
    "buildid": "20110416004121",
    "type": "metrics",
    "date": 1303152081000,
    "testkey": "telemetry-v1",
    "appid": "{a23983c0-fd0e-11dc-95ff-0800200c9a66}",
    "device": "Nexus One",
    "userkey": "",
    "osversion": "REL (10)",
    "data": {
        "reason": "manual",
        "malloc/allocated": 32377108,
        "malloc/mapped": 34603008,
        "malloc/committed": 34603008,
        "malloc/dirty": 77824,
        "js/gc-heap": 5242880,
        "js/string-data": 514630,
        "js/mjit-code": 88500,
        "storage/sqlite/pagecache": 4536536,
        "storage/sqlite/other": 1050816,
        "storage/permissions.sqlite/LookAside_Used": 29,
        "storage/permissions.sqlite/Cache_Used": 99208,
        "storage/permissions.sqlite/Schema_Used": 1272,
        "storage/permissions.sqlite/Stmt_Used": 5744,
        "storage/extensions.sqlite/LookAside_Used": 438,
        "storage/extensions.sqlite/Cache_Used": 428248,
        "storage/extensions.sqlite/Schema_Used": 6928,
        "storage/extensions.sqlite/Stmt_Used": 119024,
        "gfx/surface/image": 1088248,
        "images/chrome/used/raw": 0,
        "images/chrome/used/uncompressed": 1025124,
        "images/chrome/unused/raw": 0,
        "images/chrome/unused/uncompressed": 3648,
        "images/content/used/raw": 0,
        "images/content/used/uncompressed": 2144,
        "images/content/unused/raw": 4168,
        "images/content/unused/uncompressed": 8288,
        "layout/all": 563338,
        "storage/places.sqlite/LookAside_Used": 143,
        "storage/places.sqlite/Cache_Used": 428488,
        "storage/places.sqlite/Schema_Used": 11704,
        "storage/places.sqlite/Stmt_Used": 44152,
        "content/canvas/2d_pixel_bytes": 81120,
        "storage/cookies.sqlite/LookAside_Used": 14,
        "storage/cookies.sqlite/Cache_Used": 165000,
        "storage/cookies.sqlite/Schema_Used": 1816,
        "storage/cookies.sqlite/Stmt_Used": 0,
        "storage/formhistory.sqlite/LookAside_Used": 14,
        "storage/formhistory.sqlite/Cache_Used": 197920,
        "storage/formhistory.sqlite/Schema_Used": 1656,
        "storage/formhistory.sqlite/Stmt_Used": 0,
        "storage/addons.sqlite/LookAside_Used": 152,
        "storage/addons.sqlite/Cache_Used": 296616,
        "storage/addons.sqlite/Schema_Used": 4280,
        "storage/addons.sqlite/Stmt_Used": 29152,
        "storage/search.sqlite/LookAside_Used": 20,
        "storage/search.sqlite/Cache_Used": 99192,
        "storage/search.sqlite/Schema_Used": 1216,
        "storage/search.sqlite/Stmt_Used": 1840,
        "shmem/allocated": 0,
        "shmem/mapped": 0,
        "storage/index.sqlite/LookAside_Used": 148,
        "storage/index.sqlite/Cache_Used": 296656,
        "storage/index.sqlite/Schema_Used": 3032,
        "storage/index.sqlite/Stmt_Used": 51704,
        "uptime": 159848,
        "process": {
            "parent": {
                "user": 13,
                "system": 2,
                "rss": 77456
            },
            "child": {
                "user": 22,
                "system": 2,
                "rss": 25132
            },
            "cpu": 57
        }
    }
}

You can now access Metrics charts on Zippity to view the data. Trying to find ways to visualize the data isn’t easy. There is a lot of data. The charts are simple for now. The data point tooltip shows more detailed information.

Visit Zippity from your phone and install the add-on today. Thanks for using Zippity to help us collect data to make Firefox Mobile better.

Posted on

Firefox Mobile – Monitor HTTP Headers

I just added support to Mobile Tools for monitoring HTTP headers in Firefox Mobile. I just wanted a way to look at some HTTP traffic to help debug some mobile websites. Screen space is limited on mobile devices, so we don’t get to have nice floating panels like in desktop Firefox’s web console or Firebug. Instead I opted for a slide out panel:

Tap the little tab and the panel slides out and back. Use the Pause and Clear buttons to manage the HTTP traffic. Tap an item in the list to expand the request, response and cookie details:

You can pan the list in any direction, as needed to see the contents. The panel tab takes up very little space while browsing, but you can also hide it completely using the add-on options:

In case you don’t know, Mobile Tools also adds support for viewing Page Info and Page Source too.

Posted on

Cloud Printer – Print from Firefox Mobile

Recently, Google released the beginnings of a cloud-based printing system called – Google Cloud Print. The project is still in Beta, but you can install a recent version of Google Chrome on Windows and attach your local printers into the Cloud Print system (more). Google has added support for Cloud Print to few of their mobile web apps, but has not released a client application API yet. However, they did release a simple webapp demo – and where there is a demo, there are people reverse engineering it.

Cloud Printer is a restartless Firefox Mobile add-on that integrates into the Google Cloud Print system. Firefox Mobile already has code to save web pages as PDF. I took that code and send the PDF to the Google Cloud Print system.

Using the demo code and some other examples, it was fairly simple to get this to work. The current API is fairly simple and nice. I expect a few changes when the APIs become official, which should happen soon.

Note: You need to be signed into your Google Account for this to work. If you are not signed in, you’ll see a prompt and we open the Google Account login page for you.

Let me know how this works for you!

Restartless Fun

I like experimenting with restartless add-ons. This time I used a variation of the include technique to assign an image to the toolbar button and get access to a CSS file and IPC frame script. The CSS file is loaded and unloaded using nsIStyleSheetService. The IPC frame script is loaded using the global message manager. The frame script is needed because the PDF file must be generated in the content process, not the main process. You do remember that Firefox Mobile is multi-process, right?

One gotcha. Once loaded, you can’t currently unload a IPC frame script. So if you enabled/disable a restarless add-on that loads a frame script, you’ll end up with multiple instances running. Which means, when you send an IPC message, multiple listeners will respond – this is bad. I hacked around that by sending a “disable” message to my frame script when uninstalling the add-on. The “disable” message just removes the message listeners in the frame script so they won’t respond to any messages in the future. See the source code.

These restartless techniques are documented in various places, but we should start some code snippet docs on MDC too.

Posted on

Firefox Mobile Add-on – Cloud Viewer

I just put together a simple restartless add-on, Cloud Viewer, that integrates the Google Docs Viewer into Firefox Mobile. I saw a few similar add-ons on AMO for desktop Firefox, but none for Firefox Mobile. Opera and Dolphin also have add-ons integrating support for online document viewers.

The concept is pretty nice, especially for mobile devices: Open online documents in an online viewer. No need to waste time downloading the file and waste space on your device saving the file. Google’s viewer supports Powertpoint (PPT), Word (DOC, DOCX), Excel (XLS, XLSX), PDF and some non-web image formats. The viewer even uses a mobile UI when running on devices.

Restartless Fun – The Details

I wanted the add-on to be restartless because restartless add-ons rock. I also wanted the add-on to work at a deeper level than a context menu. I could have put a menu item on the context menu to open links in Google’s viewer, but that wouldn’t work on links that weren’t directly pointing to the file – think Google search results. The link Google gives you in a search result redirects you to the actual file, so a context menu item wouldn’t be the best solution. The redirection issue occurs more than you think on the web. Instead, I override an XPCOM component the controls how Firefox treats files the browser doesn’t natively handle. Normally, this component (nsIHelperAppLauncherDialog) starts a file download and will open the file using a local application.

Cloud Viewer overrides the component. I check the extension of the direct URI to the file and if supported, I ask the user if we should open the file in an online viewer. Since the add-on is restartless, I can’t use the normal method of registering JS XPCOM components. I have to manually register and unregister the component myself. This worked fine and was pretty easy. See the source code.

I really think we should be writing more restartless add-ons, especially the simple ones. Great UX and a really small download. Only 2.5KB XPI file for Cloud Viewer. The internal support for restartless add-ons will only keep getting better.

Posted on

Zippity & Test Harness Updates

A few weeks ago I posted about Zippity, a way for anyone to help collect performance data for Firefox Mobile. Data has been coming in and so has some feedback. I added some features to the Test Harness add-on to make it easier to use and collect some new types of data. Here’s a list of changes:

  • Added a proper in-content page for starting tests, and checking out previous result.
  • Added support for measuring startup time, as well as, SunSpider and V8 JS benchmarks.
  • Added basic support for desktop Firefox (thanks to Dietrich Ayala.)
  • Added a page timeout for pageload tests. Sometimes pages just get stuck – either a bug in Fennec or a mystery of the ether.
  • Added a simple goodput measure for pageload tests. We time how long it takes to download a 250KB test file from Zippity. It’s a simple metric we can use to categorize the pageload results.

All tests are preconfigured, you just need to tap the test you want to run and the add-on does the rest. Here’s a basic rundown of how each test works, so you have an idea of what to expect:

  • Pageload: Opens a new tab and starts loading a predefined list of pages. We load the list of pages 3 times and take the average.
  • Startup: Fennec will restart itself five (5) times, remembering the startup time for each restart and then taking the average. Startup time is defined as the time from launching the process to the end of loading the initial page.
  • SunSpider and V8: Each subtest of the benchmark is a web page, loaded and executed. The page reports the time needed to complete the subtest. The final result is the total of all subtests.


I also updated the Zippity server to support the new data types and added some new features:

  • Added graphs for viewing startup time, SunSpider and V8 results.
  • New mobile pages built using jQuery Mobile. Now you can install the add-on and view the graphs from your mobile device. Still needs some tweaks, but it’s a start.
  • Added the goodput measure to the graph tooltips. Will only appear for newly collected data that has the metric.

The SunSpider and V8 tests are taken from the Mozilla Talos test suite. The Test Harness add-on can load and time the tests just like the Talos system can, so I didn’t need to change a thing about the tests. Yes, that means I can add other Talos based page tests too, such as the DHTML and SVG tests.

I addition to some new Talos tests, I was thinking of adding some monitoring to Test Harness. Dietrich has an add-on to collect some UI responsiveness measures. I think we could add something like that to Zippity. Taras Glek has ideas for monitoring memory usage and posting the results once a day. That also sounds like a good use of Zippity.

If you use Zippity / Test Harness and have ideas, comments or found bugs – let me know. Comment here or join Mozilla IRC and look for “mfinkle” in #mobile (or several other channels).

Updated: I fixed a problem with the Pageload test manifest preference. It was pointing a 404 so the pageload tests wouldn’t work. The add-on is fixed now. Thanks AaronMT.

Posted on

Zippity – Using the Crowd to Collect Performance Data

If you’re serious about improving your application’s performance, you need to collect data. At Mozilla, we use Talos. The Mobile team has been using Talos to track performance on Maemo (using N810 and N900) devices for a few years and recently started tracking Android (using Tegras) as well. Here are a few of the metrics we track:

  • Startup (Ts)
  • Pageload (Tp)
  • HTML Rendering (Tdhtml)
  • Sunspider (Tss)

We build the application every time code is checked into the source repository. After each build, we run these performance tests and watch for changes. Regressions happen and need to be fixed as soon as possible.

One limitation of the current Talos system is the hardware variety. For Firefox Mobile, we run tests on two (2) types of hardware: N900 (Maemo) and NVidia Tegra (Android). One problem is that this doesn’t map to the real world very well. Don’t get me wrong – the current system minimizes measurement noise and we can see regressions fairly easily. However, without testing on a variety of devices, we just don’t get a good picture of how Firefox Mobile runs on your device.

Hello Zippity!

One idea that has talked about is to get the community involved in testing performance. If we could leverage many different people, using many different phones, we might get a better picture of how Firefox Mobile performs in the real world.

I created a simple add-on (Test Harness) that can install in any Firefox 4 for Mobile release and can run a series of tests. Then it posts the result to a public data server (Zippity) and anyone can view the results. When a test result is posted to Zippity, we capture a few bits of information:

  • Test Type: Pageload, startup – whatever the test might be tracking.
  • Test Manifest: What was the actual sequence performed? What series of pages did you load? This is important if we want to try to minimize noise in the results. If you want to only compare test runs that used the same input data, it can help reduce noise and make trends easier to see.
  • User Key: In case you want to only see results submitted by a particular user. The user key is completely optional. It can be used to help filter extraneous results.
  • Device Metadata: Information like device type, OS, OS version. Again, helpful for filtering.

I have been running Firefox Mobile nightly builds on several Android devices using a static set of webpages, hosted from a local webserver. Very controlled, to minimize noise and try to see small changes over time. You can see the results here.

Anyone can run the same set of live, real world pages using the add-on. Because of differences in devices, networking latency and changes to the actual website content – the results won’t be the same. That’s OK! The real world results are just as meaningful and provide just as much valuable insight.

Currently, the Test Harness add-on only sends pageload (Tp) data to Zippity, but plans are underway to extend the test types. If you want to play along, just install the Test Harness add-on. It is already configured to run the pre-defined pageset and submit the results to Zippity. Just push the button:

Zippity is still evolving and doesn’t have a lot of features. The source code should be in my Mercurial user repo soon. I’ll post more about Zippity and the Test Harness add-on as things improve.