Planet Firefox Mobile

We landed a neat new feature recently in Firefox, called Super Toast. It’s great for those times where you get notified of an action completing, but you might want to take an additional action.

The first use of Super Toast is when adding a bookmark. Instead of just telling you the bookmark was added, you now have the option of doing more with the new bookmark:

Tap on “Options” and you can edit parts of the new bookmark or add the  new bookmark to your Android home screen:

We have a few more use cases for Super Toast, so be on the look out.

June 14, 2013 06:15 PM

It took a while to hunt down a site that allowed for free hosting of 50 gigs or more and then post the file up.  There are certain modifications I had made from yesterday to the image as well.

1. There are certain files I shouldn’t host for the unagi, so having the directories pulled for them didn’t’ make sense.  I decided to get rid of those.  instead it’s a ~/Project/B2G folder that’s waiting for you to config.sh with whatever device you have. see https://developer.mozilla.org/en-US/docs/Mozilla/Firefox_OS/Preparing_for_your_first_B2G_build
2. I decided to download the marionette test cases and also install virtualenvwrapper and virtualenv.  see: https://developer.mozilla.org/en-US/docs/Marionette/Running_Tests and http://doughellmann.com/2008/05/virtualenvwrapper.html
3. I also have a separate ~/Projects/gaia folder so that you can build your own gaia.  Here are some tips and tricks : https://wiki.mozilla.org/B2G/QA/Tips_And_Tricks#B2G_Compiling_Gaia

The username is Ubuntu and the password is reverse:

https://mega.co.nz/#!9w9ihJwB!YF-zymendf-uzLnhYlssjUFcW9l6XJp31Vx4uyEoDn8

Filed under: mobifx, mobile, Planet, QA, QMO, Uncategorized Tagged: B2G, gaia, mobifx, mobile, Planet, QA, QMO

June 14, 2013 05:31 PM

Android’s ActionProviders are a really nice feature. They provide a nice way to show an alternative or a secondary context in an activity. ShareActionProvider takes them to another level. The secondary context of showing a list of shareable activities is available as a menu item. In addition, they show the most frequently used Activity for quick sharing. But they come with a downside. As the name says, ActionProviders can only be present in an ActionBar. Most of the popular android apps don’t use an ActionBar as it is very limiting. Firefox for Android has the same problem, as it doesn’t use an ActionBar. How do we provide the user with such a fast and easy access to the most frequently used activity?

Since Firefox for Android uses a custom menu, adding an ActionProvider logic inside a ListView was easy. Analogous to the ShareActionProvider, the main menu item gives the list of shareable activities as a SubMenu, and the most frequently used app is shown along with the actual menu item. To use the same metrics as Android for the frequency calculation, we chose to use the same underlying model. Android’s implementation of storing and receiving applications from an XML file, ordering the applications based on a time based weight is available in ActivityChooserModel. (Note: When used, one would have to copy this file to their code base, as this file is an internal file).

While working on this feature, I was left with so many puzzling discoveries!

• While setting an Intent with ShareActionProvider for the first time, it calls ActivityChooserModel’s setIntent(). This triggers reading the list from the history file by calling readHistoricalDataImpl(). The problem here is that, even though the comment — oops, just a comment! — says everything is done off the UI thread, the reading of a file from the disk and parsing it happens in the UI thread. This causes StrictModeViolation, and hogs the UI.
• ShareActionProvider’s setShareIntent() should be used sparsely. Though one of the Android articles touches this, the reason is not explained. Let’s say the application is a photo sharing application and it needs to update the image date when the user flips through the gallery. Calling setShareIntent() sounds the easiest way. However, setShareIntent() rebuilds the list every single time. And, as I mentioned earlier, setShareIntent() runs on the UI thread. This would result in UI jankiness. Instead, it’s better to store the Intent that was given to the ShareActionProvider, and update the EXTRA parameters in it, leaving the ACTION and MIME type intact. This way, the intent remains the same, and the data varies, without doing any work on the UI thread. But hey, there is not getter for this method! So, it’s our responsibility to store it in our class.
• Even getters in this file wants to ensure a consistent state. In case something had changed with the list of activities, either it loads them all once again, or reads from the disk. Which thread will this run on? Clicking on the Share icon, would ask the ActionProvider to get a list of activities. The event handling runs on the UI thread. This in turn ensures a consistent state and returns the items back on the UI thread. So, every setter or getter will (usually) be run on the UI thread and could cause considerable work to be done on the main thread.
• Lets say, some other application wants to expose Share with a custom ActionProvider like Firefox for Android. When they try to use the ActivityChooserModel, there is a reference to PackageMonitor. Unfortunately this file is internal and has a lot of other internal dependencies. Commenting the related code will leave the history file, and the list in a stale state if some other shareable app is installed/uninstalled while this app is in the background.

Phew! Basically ShareActionProvider is some sort of a UI hog, if not used correctly. ActionProviders cannot be used outside of ActionBar, even though they provide a nice paradigm. Why Android, why?

June 13, 2013 05:39 AM

Quick Share remembers your commonly used sharing application and displays it on the menu to make sharing even easier. Just a quick tap on the icon to share the web page.

June 11, 2013 06:57 PM

In the dub-dub-dub browser world, there’s a lot of need for the dot-dot-dot. The pages titles are exponentially long, to make sure Google indexes them, and they don’t fit properly on a small screen. For e.g., CNN shows a very long title that cannot be shown comfortably in a ListView‘s row. Firefox used to show ellipsis and truncate the text in such cases. However, there are a couple of problems: An ellipsis in the middle cuts the text off in such a way that the context is lost; an end ellipsis is not good from a design point of view. To mitigate this problem, we wanted a TextView that fades in the end. (Design philosophy: Show a small path, and leave the imagination to the viewer).

To show a faded TextView, we need to know when, how and how much to fade. The amount of fading needed can be exposed as an attribute, say fadeWidth for the custom view. When to fade part becomes easier if we can constrain the TextView to a single line and see if the text runs longer than available width. The XML for such a view would look like:

    <com.sriramramani.widget.FadedTextView android:layout_width="wrap_content"
                                           android:layout_height="wrap_content"
                                           android:singleLine="true"
                                           android:ellipsize="none"
                                           sirius:fadeWidth="30dp"/>

Every TextView is backed by a Layout, that holds the information on how to draw the text on the screen. This includes the number of lines, text in each line, the line ascent, baseline, etc. Unfortunately, the getWidth() on the layout returns a very huge number. Fortunately, we know that the TextView will have only one line. Using getLineWidth(0), we can find the width of the first line — the entire text.

    // ... somewhere in the custom text view.
    Layout layout = getLayout();
    if (layout.getLineWidth(0) > getMeasuredWidth()) {
        // add fading.
    } else {
        // don't add fading.
    }

That was simple! How do we add a fading effect to the end? The LinearGradient can take a range of colors and stops, and can be added as a Shader to a Paint. Voila!

    // ... somewhere in the custom text view.
    float start = 0.0f;
    float end = getMeasuredWidth();

    // mFadeWidth is obtained from the attribute.
    float stop = ((float) (end - mFadeWidth) / (float) end);

    // Setup the linear gradient.
    LinearGradient gradient = new LinearGradient(0, 0, end, 0,
                                                 new int[] { color, color, Color.TRANSPARENT },
                                                 new float[] { 0, stop, 1.0f }
                                                 Shader.TileMode.CLAMP);

Let’s build the entire custom view now.

public class FadedTextView extends TextView {

    // Width of the fade effect from end of the view.
    private int mFadeWidth;

    // Add other constructors too.
    public FadedTextView(Context context, AttributeSet attrs, int defStyle) {
        super(context, attrs, defStyle);

        TypedArray a = context.obtainStyledAttributes(attrs, R.styleable.FadedTextView);
        mFadeWidth = a.getDimensionPixelSize(R.styleable.FadedTextView_fadeWidth, 0);
        a.recycle();
    }

    @Override
    public void onDraw(Canvas canvas) {
        int width = getMeasuredWidth();

        // Layout doesn't return a proper width for getWidth().
        // Instead check the width of the first line, as we've restricted to just one line.
        if (getLayout().getLineWidth(0) > width) {
            // Always get the current text color before setting the gradient.
            int color = getCurrentTextColor();

            // [0..stop] will be current text color, [stop..1] will be the actual gradient
            float stop = ((float) (width - mFadeWidth) / (float) width);

            // Set up a linear gradient.
            LinearGradient gradient = new LinearGradient(0, 0, width, 0,
                                                         new int[] { color, color, Color.TRANSPARENT },
                                                         new float[] { 0, stop, 1.0f },
                                                         Shader.TileMode.CLAMP);
            getPaint().setShader(gradient);
        } else {
            getPaint().setShader(null);
        }

        // Do a default draw.
        super.onDraw(canvas);
    }
}

This doesn’t take care of compound drawables and their padding. But that’s pretty straightforward as there are methods to access their properties. And that’s how we kill the ellip…sis.

June 07, 2013 12:07 AM

Sometimes apps would need creating ColorDrawable in Java instead of using an XML. Usually, these colors are specified in colors.xml. And the corresponding code to create such a drawable would look like,

    <!-- ... in res/values/colors.xml ... -->
    <resources>
        <color name="background_color">#FF00FF00</color>
    </resources>

    // ... in some java file ...
    something.setBackground(new ColorDrawable(getResources().getColor(R.color.background_color)));

The other way round is to create a ShapeDrawable with the required color.

    <!-- ... in res/drawable/background_color.xml ... -->
    <shape android:shape="rectangle">
        <solid android:color="#FF00FF00">
    </shape>

Actually, Android has a better and shorter way of creating such drawables! Instead of specifying a color and using it, we can directly create a <drawable>.

    <!-- ... in res/values/colors.xml -->
    <resources>

        <!-- note: this uses "drawable" instead of "color" -->
        <drawable name="background_color">#FF00FF00</drawable>

    </resources>

And this can be used in Java as,

    // ... in some java file ...
    // note: it's referred as R.drawable and not R.color.
    something.setBackground(getResources().getDrawable(R.drawable.background_color));

May 31, 2013 06:19 AM

The May 2013 summary of performance measures for Firefox for Android.

Significant regression in RSS measures was caused by bug 848764 and is expected; see discussion in bug.

Talos

This section tracks Perfomatic graphs from graphs.mozilla.org for mozilla-central builds of Native Fennec (Android 2.2 opt). The test names shown are those used on tbpl. See https://wiki.mozilla.org/Buildbot/Talos for background on Talos.

tcheckerboard

Simple measure of “checkerboarding”. Lower values are better.

0.0 (start of month) – 0.0 (end of month).

tcheck2

Measure of “checkerboarding” during simulation of real user interaction with page. Lower values are better.

4.0 (start of month) – 4.0 (end of month).

trobopan

Panning performance test. Value is square of frame delays (ms greater than 25 ms) encountered while panning. Lower values are better.

14000 (start of month) – 12000 (end of month).

There is noise in this test; it’s not clear if there was an actual improvement this month.

tprovider

Performance of history and bookmarks’ provider. Reports time (ms) to perform a group of database operations. Lower values are better.

375 (start of month) – 375 (end of month).

tsvg_nochrome

Page load test for svg. Lower values are better.

3800 (start of month) – 3800 (end of month).

tp4m_nochrome

Generic page load test. Lower values are better.

780 (start of month) – 680 (end of month).

Improvement on May 16.

Bug 877779 – Talos Regression tp4m_nochrome 14% on Android 2.2, May 29

tp4m_main_rss_nochrome

90000000 (start of month) – 125000000 (end of month).

The significant regression on May 20 is an expected change — see bug 848764, especially comments 6 – 13.

tp4m_shutdown_nochrome

25000000 (start of month) – 25000000 (end of month).

ts

Startup performance test. Lower values are better.

3800 (start of month) – 3800 (end of month).

ts_shutdown

Shutdown performance test. Lower values are better.

25000000 (start of month) – 25000000 (end of month).

Throbber Start / Throbber Stop

These graphs are taken from http://mrcote.info/phonedash/#/.  Browser startup performance is measured on real phones (a variety of popular devices).

“Time to throbber start” measures the time from process launch to the start of the throbber animation. Smaller values are better.

“Time to throbber stop” measures the time from process launch to the end of the throbber animation. Smaller values are better.

Notice that some of these devices are reporting highly variable results — see bug 877812.

Eideticker

These graphs are taken from http://eideticker.mozilla.org. Eideticker is a performance harness that measures user perceived performance of web browsers by video capturing them in action and subsequently running image analysis on the raw result.

More info at: https://wiki.mozilla.org/Project_Eideticker

awsy

See https://www.areweslimyet.com/mobile/ for content and background information.

Again, notice the regression around May 20 — bug 848764.

May 30, 2013 09:55 PM

For a while now we've had problems stemming from having to deal with too many coordinate systems. I blogged about this before and the problem has only gotten worse. The AsyncPanZoomController class in particular deals with a variety of coordinate systems and it's often not clear which coordinate system a particular variable is in.

To try and deal with these code complexity issues, Anthony Jones suggested adding template parameters to some of the gfx classes so that we can enforce unit conversions at compile-time and annotate variables with which units they're in. I filed bug 865735 for this, and after some discussion with roc, Bas, jrmuizel, BenWa, tn, Cwiiis and some others, we agreed on a way to do this. I landed that patch and it was merged to m-c today.

The patch allows for incrementally adding units to uses of gfx::Point, gfx::Size, and gfx::Rect (and their Int variations). By default all instances of these classes are tagged as UnknownUnits. As we update bits of code they will be changed to things like CSSPixels, LayerPixels, ScreenPixels, and so on, depending on what they are. I've been working on a couple of patches that start adding this extra information to pieces of code; these patches can be found on bug 877726 and bug 877728. Doing this is slow work, but very parallelizable, so I would appreciate any help I can get. If you know of some graphics code that uses these classes, and you know what units they data they hold are in, please file a bug with patches to convert them. Feel free to CC me and/or make it depend on bug 865735.

They key files that define the templates and units are located at gfx/2d/Point.h, gfx/2d/Rect.h, and layout/base/Units.h. gfx::Point is now just a typedef to gfx::PointTyped<UnknownUnits>. Replacing UnknownUnits with CSSPixel gives us the new type gfx::PointTyped<CSSPixel> to represent points in CSS pixel coordinate systems. Since this is long and unwieldy to type, we have typedef'd this to CSSPoint. Similar changes will be done for the other classes (e.g. CSSIntPoint, CSSRect) and units (e.g. LayerPoint) as we start propagating them. The neat thing about the templating structure we came up with is that gfx::PointTyped<CSSPixel> actually extends from CSSPixel, so we can add methods (e.g. conversion to app units) there that are available on all CSSPoint instances but not other unit classes.

As far as I understand things, layout code currently always keeps nsPoint instances in app units (1/60 of a CSS pixel). nsIntPoint, however, can be used for a variety of units, and many of these (particularly the ones outside layout/) should be converted to gfx::IntPointTyped<something>. What layout code refers to as "device pixels" is generally not the same thing that graphics code refers to as "device pixels", so I'm trying to avoid using the term "device pixels" entirely in graphics code - I prefer to use "layer pixels", "display pixels", and "screen pixels" as needed. For non-OMTC platforms "screen pixels" and "layer pixels" should be equivalent, and for platforms without hidpi adjustments, "display pixels" and "screen pixels" should be the same.

While converting code I've run into many places where new point variables are constructed using the .x and .y members of a different point variable. It's important to ensure that such code is carefully audited to make sure that the old and new variables are in the same units. If it's not clear, it's best to stick in a call to FromUnknownUnits(...) so that it is implicitly flagged for follow-up when other nearby code gets converted.

May 30, 2013 05:31 PM

The Robocop test suite continues to evolve, providing more and more UI-level testing for Firefox for Android. Recently added tests include:

testImportFromAndroid
testOrderedBroadcast
testSharedPreferences
testAddSearchEngine
testInputAwesomeBar

testOrderedBroadcast and testSharedPreferences are examples of hybrid tests that make xpcshell-like assertions in Javascript, in a page loaded by the full browser, inside the Robocop framework. These leverage exciting infrastructure changes landed by :nalexander in bug 870908.

Of course, Robocop has had its share of problems too. We have had to disable some tests because of repeated failures. There is active, on-going work to fix and re-enable some disabled tests, but I fear that we have all but forgotten others. I am concerned about these long-disabled tests:

# [test_bug720538] # see bug 746876
# [testPasswordEncrypt] # see bug 824067
# [testThumbnails] # see bug 813107
# [testPermissions] # see bug 757475
# [testJarReader] # see bug 738890

Do you have insight into any of these neglected tests? Want to see them enabled ASAP? Or is it time to remove them completely? Let me know — :gbrown on #mobile.

May 24, 2013 07:55 PM

The fastest way to open a favorite webpage is by using a shortcut on your Android home screen. You can add a home screen shortcut from inside Firefox. The “Add to Home Screen” context menu action can be found on several menus:

• Long tap on the URL toolbar
• Long tap on the Top Sites, Bookmarks or History pages

May 21, 2013 07:41 PM

As engineers, I believe the way we approach a problem is as important as the code we write. This is especially relevant in the context of UI engineering where design is such a vital element.

Unfortunately, it seems quite hard to find good content about everything that happens around us and inside our heads when we are building user interfaces. This is what The Layout is about.

My intent is to create a space for high quality content discussing the principles, mindset, and practices that I believe shape the craft of UI engineering. It is meant to be a shared space with many voices—so, expect some awesome guest authors.

I’ve just posted the very first article, Mind the Gap. My plan is to publish a new article every other week-ish. For now, subscribe to the RSS feed or simply follow The Layout on Twitter or Google+ to get future updates.

I really hope you enjoy it!

May 17, 2013 05:28 AM

Already got the tab open? Just quickly switch to it!

May 10, 2013 07:33 PM

Almost two years, I experimented with using the dominant color of a favicon to give a small icon a colorful background. And over the past week, I wrote some patches to incorporate this design into Firefox for Android!

The simple algorithm I wrote long ago was done in JS with canvas, but to use this in our native Android UI, it’s simplest to just do it in Java. Luckily, we already had a dominant color utility method in the tree, but creating a background and border with different saturation levels was trickier than I thought it would be. To solve this problem, I gave the ImageView a background drawable with a solid white interior and a gray border, then applied a transparent version of the dominant color as a color filter. This worked pretty well once I figured out which PorterDuff mode to use, but it made me appreciate the simplicity of CSS.

When testing with various icons, I found that our dominant color algorithm could use some improvement. Our Java algorithm is different than the one I experimented with in JS mainly because it uses the HSV color model as opposed to RGB. Instead of counting every distinct color, we split the range of hues into different bins and find the bin that holds the most colors. For the winning bin, we compute the average H, S, and V values within that bin, and return that as the dominant color. To make sure we only return colorful colors, we ignore transparent pixels, as well as pixels that are close enough to black or white. This simple algorithm may not be perfect, but it works pretty well for us, especially for small favicons.

As an interesting bit of history, after I blogged about my dominant color experiment, Mardak wrote an add-on that used an improved version of my JS snippet. At the time, Wes saw this add-on and incorporated the code into XUL Fennec to create icons for homescreen shortcuts. During the Fennec Native rewrite, Wes reimplemented this feature in Java, and that’s the code I found myself in last week. And for those interested in a more robust solution implemented in JS, there’s actually a toolkit service that does this now.

May 08, 2013 06:37 PM

Firefox for Android has always shown the page title in the toolbar. Many people like this, but a growing group of vocal voices would rather see the page URL in the toolbar. Seeing the URL can help confirm you are actually on the real page and not being phished.

Fennec Nightly adds support for showing the URL, with domain highlighting.

To activate, go to Settings> Title bar > Show page address

May 08, 2013 03:08 PM

[ For more information on the Eideticker software I'm referring to, see this entry ]

I just put up a proof of concept Eideticker dashboard for FirefoxOS here. Right now it has two days worth of data, manually sampled from an Unagi device running b2g18. Right now there are two tests: one the measures the “speed” of the contacts application scrolling, another that measures the amount of time it takes for the contacts application to be fully loaded.

For those not already familiar with it, Eideticker is a benchmarking suite which captures live video data coming from a device and analyzes it to determine performance. This lets us get data which is more representative of actual user experience (as opposed to an oft artificial benchmark). For example, Eideticker measures contacts startup as taking anywhere between 3.5 seconds and 4.5 seconds, versus than the 0.5 to 1 seconds that the existing datazilla benchmarks show. What accounts for the difference? If you step through an eideticker-captured video, you can see that even though something appears very quickly, not all the contacts are displayed until the 3.5 second mark. There is a gap between an app being reported as “loaded” and it being fully available for use, which we had not been measuring until now.

At this point, I am most interested in hearing from FirefoxOS developers on new tests that would be interesting and useful to track performance of the system on an ongoing basis. I’d obviously prefer to focus on things which have been difficult to measure accurately through other means. My setup is rather fiddly right now, but hopefully soon we can get some useful numbers going on an ongoing basis, as we do already for Firefox for Android.

May 06, 2013 10:23 PM

For the last week I’ve been using a Geeksphone Keon as my only phone. There’s been no cheating here, I don’t have a backup Android phone and I’ve not taken to carrying around a tablet everywhere I go (though its use has increased at home slightly…) On the whole, the experience has been positive. Considering how entrenched I was in Android applications and Google services, it’s been surprisingly easy to make the switch. I would recommend anyone getting the Geeksphones to build their own OS images though, the shipped images are pretty poor.

Among the many things I missed (Spotify is number 1 in that list btw), I could have done with a countdown timer. Contrary to what the interfaces of most Android timer apps would have you believe, it’s not rocket-science to write a usable timer, so I figured this would be a decent entry-point into writing mobile web applications. For the most part, this would just be your average web-page, but I did want it to feel ‘native’, so I started looking at the new building blocks site that documents the FirefoxOS shared resources. I had elaborate plans for tabs and headers and such, but turns out, all I really needed was the button style. The site doesn’t make hugely clear that you’ll actually need to check out the shared resources yourself, which can be found on GitHub.

Writing the app was easy, except perhaps for getting things to align vertically (for which I used the nested div/”display: table-cell; vertical-alignment: middle;” trick), but it was a bit harder when I wanted to use some of the new APIs. In particular, I wanted the timer to continue to work when the app is closed, and I wanted it to alert you only when you aren’t looking at it. This required use of the Alarm API, the Notifications API and the Page Visibility API.

The page visibility API was pretty self-explanatory, and I had no issues using it. I use this to know when the app is put into the background (which, handily, always happens before closing it. I think). When the page gets hidden, I use the Alarm API to set an alarm for when the current timer is due to elapse to wake up the application. I found this particularly hard to use as the documentation is very poor (though it turns out the code you need is quite short). Finally, I use the Notifications API to spawn a notification if the app isn’t visible when the timer elapses. Notifications were reasonably easy to use, but I’ve yet to figure out how to map clicking on a notification to raising my application – I don’t really know what I’m doing wrong here, any help is appreciated! Update: Thanks to Thanos Lefteris in the comments below, this now works – activating the notification will bring you back to the app.

The last hurdle was deploying to an actual device, as opposed to the simulator. Apparently the simulator has a deploy-to-device feature, but this wasn’t appearing for me and it would mean having to fire up my Linux VM (I have my reasons) anyway, as there are currently no Windows drivers for the Geeksphone devices available. I obviously don’t want to submit this to the Firefox marketplace yet, as I’ve barely tested it. I have my own VPS, so ideally I could just upload the app to a directory, add a meta tag in the header and try it out on the device, but unfortunately it isn’t as easy as that.

Getting it to work well as a web-page is a good first step, and to do that you’ll want to add a meta viewport tag. Getting the app to install itself from that page was easy to do, but difficult to find out about. I think the process for this is harder than it needs to be and quite poorly documented, but basically, you want this in your app:

if (navigator.mozApps) {
  var request = navigator.mozApps.getSelf();
  request.onsuccess = function() {
    if (!this.result) {
      request = navigator.mozApps.install(location.protocol + "//" + location.host + location.pathname + "manifest.webapp");
      request.onerror = function() {
        console.log("Install failed: " + this.error.name);
      };
    }
  };
}

And you want all paths in your manifest and appcache manifest to be absolute (you can assume the host, but you can’t have paths relative to the directory the files are in). This last part makes deployment very awkward, assuming you don’t want to have all of your app assets in the root directory of your server and you don’t want to setup vhosts for every app. You also need to make sure your server has the webapp mimetype setup. Mozilla has a great online app validation tool that can help you debug problems in this process.

Visiting the page will offer to install the app for you on a device that supports app installation (i.e. a Firefox OS device). Not bad for a night’s work! Feel free to laugh at my n00b source and tell me how terrible it is in the comments

May 04, 2013 08:37 AM

Firefox for Android UI Hackathon, Spring 2013

Hackathons are a great way to get a bunch of people sprinting through a very focused body of work, and they’re also great fun to do.

And much to the UX team’s delight, our engineering team recently organized one that was focused solely on UI polish bugs! We almost always have a backlog of subtle but important refinements we’d like to add to Firefox, and while we are incredibly lucky to work with an engineering team that values good design, there are still only so many hours in the day and only so much of peoples’ time available to make fixes. This was a great opportunity to sand down some of the rough edges we had been thinking about for a while.

The hackathon bugs had to be simple enough fixes that could be made in the short time frame of the hackathon, so brand new features were off the table. This was all about polish. And in order for the sprint to be successful, there couldn’t be any road blocks or missing details, so I made sure that whichever ones people wanted to work on had the most up to date instructions and designs ready to go.

—

This was our short list when we kicked off the hackathon. https://bugzilla.mozilla.org/buglist.cgi?quicksearch=sw%3Aui-hackathon

Over the course of a few days, the team knocked off *19* of these bugs. Some of the most visible improvements included:

New tab counter icon

We recently simplified the title bar area to use a single ‘background layer’ colour. For the hackathon we also revisited the icon design to more clearly communicate what would happen when you tapped it, using a visual metaphor that has become more or less the standard for tabs on mobile web browsers. Some earlier design explorations are shown below.  / http://bugzil.la/863379

New tab increment animation

We also wanted to add a little dimension to the new tab counter icon, so we added a fun transition that appears when you create a new a tab.  / http://bugzil.la/863828

Refined tab tray transition

We have been exploring ways of making the tab tray opening feel more fluid and interesting. Below is an example of a parallax-like transition we experimented with for opening the tab tray. A slightly simplified adaptation of the animation below is in our Nightly build. / http://bugzil.la/864960

Text labels in the tab tray

The tab section icons that existed in the previous design didn’t communicate the section contents as clearly as we would have liked, so we replaced them with text labels. / http://bugzil.la/862996

Increased Reader Mode touch target size

Kind of a no brainer, but for some reason the touch area was tiny here for a long time. / http://bugzil.la/862755

Reader Mode refinements

We recently added an option to use Charis — a serif typeface — in our Reader Mode, and it makes for a very pleasant read. / http://bugzil.la/862445

Dominant colour sampling for favicon backgrounds

We display large favicons whenever we can, but many websites still only provide 16px favicons. This often makes for rather dissonant looking lists in our UI. Adding a tint of the favicon’s dominant colour to the background makes individual list items more quickly recognizable, and makes the lists look a little more designed overall. We’ll also use this approach for thumbnail boxes in cases where a screenshot of the website is unavailable. / http://bugzil.la/837392

Optional title bar URLs

We added a setting to let users display URLs in the title bar, instead of page titles. / http://bugzil.la/778216

—

Not bad for a couple of days of work, right? A huge thanks to Lucas Rocha for organizing the event, and to the Firefox for Android front-end team and all the contributors who participated in our hackathon. Each one of these tweaks are wonderful refinements on their own, and having watched all of them land in the course of a few days was truly delightful. The next few releases are shaping up to be pretty special on Firefox for Android.

Of course, as always if you don’t want to wait for the update on Google Play, you can try out all of these enhancements _right now_ by downloading one of our Firefox Nightly builds. Enjoy!

May 03, 2013 08:27 PM

Firefox for Android Hits 4.5 Stars:

1 year ago, I started a spreadsheet. For 9 months we’d been rewriting Firefox for Android from the ground up, and on May 16, 2012 we release…

May 02, 2013 07:04 PM

We are gradually running more and more xpcshell tests for Android on tbpl.

Do you have a favorite xpcshell test that you are eager to see running on Android ASAP?

Do you know of certain xpcshell tests that should not be run on Android?

Let me know, or comment in bug 865006.

May 01, 2013 04:17 AM

Talos

This section tracks Perfomatic graphs from graphs.mozilla.org for mozilla-central builds of Native Fennec (Android opt). The test names shown are those used on tbpl. See https://wiki.mozilla.org/Buildbot/Talos for background on Talos.

tcheckerboard

Simple measure of “checkerboarding”. Lower values are better.

0.0 (start of month) – 0.0 (end of month).

tcheck2

Measure of “checkerboarding” during simulation of real user interaction with page. Lower values are better.

3.5 (start of month) – 4.0 (end of month).

Bug 866113 – Talos Regression tcheck2 26% on Android 2.2, Apr 26

trobopan

Panning performance test. Value is square of frame delays (ms greater than 25 ms) encountered while panning. Lower values are better.

12000 (start of month) – 14000 (end of month).

There is noise in this test; it’s not clear if there was an actual regression this month.

tprovider

Performance of history and bookmarks’ provider. Reports time (ms) to perform a group of database operations. Lower values are better.

375 (start of month) – 375 (end of month).

tsvg_nochrome

Page load test for svg. Lower values are better.

4000 (start of month) – 3800 (end of month).

tp4m_nochrome

Generic page load test. Lower values are better.

720 (start of month) – 780 (end of month).

Bug 864637 – 11% Android Tp4 NoChrome regression on 2013-04-18

tp4m_main_rss_nochrome

88000000 (start of month) – 90000000 (end of month).

Gradual regression — no bug.

tp4m_shutdown_nochrome

25000000 (start of month) – 25000000 (end of month).

ts

Startup performance test. Lower values are better.

3800 (start of month) – 3800 (end of month).

ts_shutdown

Shutdown performance test. Lower values are better.

25000000 (start of month) – 25000000 (end of month).

Throbber Start / Throbber Stop

These graphs are taken from http://mrcote.info/phonedash/#/.  Browser startup performance is measured on real phones (a variety of popular devices).

“Time to throbber start” measures the time from process launch to the start of the throbber animation. Smaller values are better.

“Time to throbber stop” measures the time from process launch to the end of the throbber animation. Smaller values are better.

Eideticker

These graphs are taken from http://eideticker.wrla.ch. Eideticker is a performance harness that measures user perceived performance of web browsers by video capturing them in action and subsequently running image analysis on the raw result.

More info at: https://wiki.mozilla.org/Project_Eideticker

awsy

See https://www.areweslimyet.com/mobile/ for content and background information.

April 30, 2013 11:07 PM

Last week, we did our very first topic-oriented hackathon focused on UI polishing bugs. The UI changes we’ve done will make a substantial difference in the experience of using Firefox on Android. Here are some of my favourite fixes and improvements.

Tabs

Details in the tabs UI can make a big difference UX-wise. We changed the tabs button icon (see image) to provide better affordance. The new icon also features a much cooler animation when tabs are added or removed.

Last but not least, we added a subtle parallax effect when you the open/close the tabs panel giving it a more fluid feel.

Address bar

As Wes has already reported, you now have the option to show URLs instead of page titles in the address bar. The domain highlight (see image) is a nice touch and gives us feature parity with Firefox on desktop.

The reader and stop buttons now have properly sized hit areas to avoid tapping other parts of the toolbar by mistake—a long overdue issue.

That’s not all

Reader Mode will get some nice style updates for serif fonts, doorhanger notifications now have a more polished animation, text selection handles have a more consistent style, favicons in the awesomescreen will look fancier, some visual glitches in the awesomescreen and toolbar were fixed, and more.

Not all these changes are in Nightly just yet but they will show up in the next days. Firefox 23 has everything to be my favourite release ever. Download and install our Nightly build on your Android and let us know what you think.

April 29, 2013 02:15 PM

One common request we get in Fennec is the ability to show url’s in the titlebar. At one point I even wrote an addon to do it. Ignoring the arguments for and against, the feature is finally available built in to Nightly builds:

To enable, just open Settings -> Privacy and change the “Title Bar” pref to “Show page address”. We’ve also set up domain highlighting like you see on desktop Firefox (for both regular and private tabs show above, with or without Personas enabled, although Personas are a nice security measure for our new scroll away urlbar too!). Enjoy!

April 29, 2013 05:43 AM

You can install Firefox from the Yandex Store.

April 22, 2013 06:26 PM

Another update on getting Eideticker working with FirefoxOS. Once again this is sort of high-level, looking forward to writing something more in-depth soon now that we have the basics working.

I finally got the last kinks out of the rig I was using to capture live video from FirefoxOS phones using the Point Grey devices last week. In order to make things reasonable I had to write some custom code to isolate the actual device screen from the rest of capture and a few other things. The setup looks interesting (reminds me a bit of something out of the War of the Worlds):

Here’s some example video of a test I wrote up to measure the performance of contacts scrolling performance (measured at a very respectable 44 frames per second, in case you wondering):

Surprisingly enough, I didn’t wind up having to write up any code to compensate for a noisy image. Of course there’s a certain amount of variance in every frame depending on how much light is hitting the camera sensor at any particular moment, but apparently not enough to interfere with getting useful results in the tests I’ve been running.

Likely next step: Create some kind of chassis for mounting both the camera and device on a permanent basis (instead of an adhoc one on my desk) so we can start running these sorts of tests on a daily basis, much like we currently do with Android on the Eideticker Dashboard.

As an aside, I’ve been really impressed with both the Marionette framework and the gaiatests python module that was written up for FirefoxOS. Writing the above test took just 5 minutes — and the code is quite straightforward. Quite the pleasant change from my various efforts in Android automation.

April 22, 2013 03:32 PM

Something I've wanted for a while is a way to receive notifications of commits to specific folders in mozilla-central, with some reasonable amount of diff included. Well, turns out there are now a bunch of ways to do this, so here's a quick rundown.

• hgweb's Atom feed - I'm only including this for completeness, but you can get an Atom feed of all changes to the repository by using the RSS icon at the bottom of any page in the repo. Unfortunately, the feed is for all changes to the repo (can't filter by particular folders/files) and doesn't include diffs, so it's limited in usefulness.
• Dave Townsend's Hg Change Feed - Dave Townsend recently set up a more comprehensive feed system and blogged about this (see blog post or jump straight to the tree navigator to subscribe). He has it set up for comm-central, mozilla-central, and mozilla-inbound, and you can watch any folder/file in any of these repos. Pretty nifty! However, the RSS feeds don't include diffs.
• RSS to email options - Both of the above options give you RSS or Atom feeds, but some people prefer to get this as email. IFTTT recipes are a simple way to do this; Dave Townsend set up one for the toolkit folder and Margaret created one for the mobile folder. If you use Zimbra to manage your mail, you can also use that to get RSS as email; you can set this up in the web interface when you create a new folder. As is to be expected, these options just convert the RSS item to email, and so also don't contain diffs.
• My mailing lists - Since I really really wanted to get diffs in the email notifications, I decided to roll my own solution. I already have an Amazon EC2 instance running for ZNC, so I cloned mozilla-central there, and wrote a quick script to pull the tree, look for changes in specific folders, and send an email using Amazon SES (free for the volume I'm sending at). The email goes to a mailman instance I also set up on this domain, so anybody who is interested can sign up. Right now I have mailing lists for mobile/ and widget/android/, since that's what I'm interested in, but I can add other folders if there is sufficient demand. With this approach it requires some work on my part to set it up for specific files and folders, but I get diffs in the emails and can customize it further as I find things that would be useful.

Did I miss any options? Post in the comments.

April 22, 2013 02:11 PM

Smoothie makes it really easy to load ListView/GridView items asynchronously, off the UI thread. It handles all the complexity from gestures, threads, scrolling state, preloading, and view recycling behind a simple API.

Up until now, one of the biggest limitations of the Smoothie API has been the lack of proper support for multi-part items. What is a multi-part item? It’s a ListView/GridView item composed by multiple parts that have to be loaded asynchronously with different priorities as you scroll.

Classic example: a list of photos with items composed by the photo image and the author’s avatar—both loaded from the cloud. With the existing API,  Smoothie would force you to load the whole content of each item in one go. This means you were forced to load both the main photo image and the avatar image for each item before loading the next item in the list.

What if you wanted to start loading the main photo image of all visible items before loading their respective avatars? The photos are probably the content your users are actually interested in after all. That’s what the multi-part item support is about. It allows you to split the loading of each item into multiple asynchronous operations with different global priorities.

So, how would you implement the above example assigning higher priority to the main photo image over the avatar using Smoothie? Assuming you’re already familiar with Smoothie’s API, just follow these steps:

1. Override the getItemPartCount() method from ItemLoader. Return the number of parts the item in the given Adapter position has.
2. Handle the new itemPart argument accordingly in loadItemPartFromMemory(), loadItemPart(), and displayItemPart(). These methods will be called once for each item part.

The item parts will have indexes starting from zero. e.g. for items with 2 parts, the part indexes will be 0 and 1. The indexes also define the relative priority between parts. Smoothie will load the part with index 0 for all visible items before loading part with index 1.

Important note: I had to break API backwards compatibility. If you don’t really need multi-part items, the only change you’ll have to make in your code is to subclass from SimpleItemLoader instead of ItemLoader. SimpleItemLoader is an ItemLoader specialized in single-part items that hides all the part-related bits from the API.

The updated documentation contains code samples and a more detailed overview of the new API. Grab the latest code while it’s hot. Feedback, bug reports, and patches are all very welcome as usual.

April 22, 2013 11:51 AM

We’ve been discussing the idea of doing periodic topic-oriented hackathons in the front-end team. The idea is simple: pick a topic—a specific part or aspect of the product—and have the whole team focused on it for a couple days. The goal is to bring substantial and fast improvements on specific areas.

As an initial experiment, we’ll be doing the first hackathon this week from Wednesday to Friday and we’re going to focus on UI polishing bugs—those UI papercuts that are not so prominent in isolation but, when fixed en masse, make a whole lot of difference.

It’s important to have a good list of bugs before we begin. So, you can start nominating Fennec bugs for the hackathon now by tagging them with “ui-hackathon”. We’ll cleanup this list and maybe prioritize them a bit during the planning session on the first day of the hackathon.

As usual, everyone is welcome to participate. You can help us by tagging bugs, or better yet, fixing them. Have a look at the wiki page for more details on the agenda.

April 22, 2013 09:51 AM

When you type a non-URL into Firefox, we search for the terms using the default search provider. You can now change the default provider.

April 20, 2013 09:14 PM

Domain auto-completion support lands in Nightly. Navigate with even less typing!

April 19, 2013 09:06 PM

Faster LocalStorage:

Honza Bambas lands a faster implementation of LocalStorage in Nightly

April 18, 2013 07:32 PM

WebRTC Support on Android:

Gian-Carlo talks about the initial WebRTC support that just landed in Nightly.

April 17, 2013 07:37 PM

Yesterday, WebRTC support landed in Firefox for Android, which means it is available in today's Nightly. Wait a minute, you might say, didn't you demo this already at MWC a month and a half ago? Well yes. But to get the code used for that demo landed in the main Firefox repository (instead of a branch), some cleanup work was needed, and we needed to make sure that older, pre-ICS phones didn't just blow up when you tried to make a phone call on them.

Although, in theory, WebRTC should work on any device Firefox for Android supports, for an ideal experience you're going to want to have an Ice Cream Sandwich or Jelly Bean device. We'll do what we can for older devices, but realistically Android was missing some essential APIs before that time (especially before Android 2.3) and device performance will also limit what experience you get. Nevertheless I had no problems getting a video call up on my Galaxy Tab 10.1 with Android 3.2, and many devices will probably work just fine.

By default WebRTC is included in Firefox for Android, but behind a preference that is off by default. To enable, flip these preferences to "true":

• media.navigator.enabled
• media.peerconnection.enabled

Secondly, because the UI is currently very provisional, you might want to disable the dialog that asks for permission to use your camera and microphone (but remember the implications of this, you probably don't want to keep it that way after testing!). Enable this setting:

• media.navigator.permission.disabled

Some example pages for WebRTC APIs are here:

• Mozilla WebRTC landing page

Note that as the code only just landed, there are going to be bugs. Some known ones are the permissions dialog (if enabled) only remembering the first choice you make, giving you audio or video, but not both, and when disabling permissions, we always take the first camera, which is probably the one you didn't want. On some devices the video might be upside down, too. Expect most of these to be fixed in the next days and weeks. If you find any bugs that I haven't listed here, feel free to file in Bugzilla and we'll get to work on them.

April 17, 2013 07:06 PM

Search gets easier in Nightlies. We show your search terms in the URLbar instead of the long, strange search URL.

April 17, 2013 06:46 PM

Firefox for Android has a background system built-in that allows Mozilla to broadcast important messages to Firefox users. We use it when we need to deliver a message quickly, even if Firefox is not running.

We had a chance to test this system:

A few days ago, we broke the update system in Nightly, meaning people would be stuck on an old version and never be able to automatically update to a new version. It happens sometimes.

The broadcast announcement made it easier to let people know about the problem and give them a way to get back on updates. 

April 12, 2013 01:11 PM

OdinMonkey (asm.js support) landed on Android ARMv7 and x86 Nightlies. IonMonkey landed in Android ARMv6 Nightlies. Along with the new Baseline Compiler, JavaScript performance is on fire. Check out the graphs.

April 10, 2013 02:05 AM

Blocking popups, sharing location, saving passwords, storing offline data and the list goes on. Web sites can ask your permission to enable and use several Web APIs. The list keeps getting longer too.

After making a decision to allow or not allow a web site to do something, how do you manage those permissions? In Firefox for Android, the URLBar long-tap menu offers a way to manage a web site’s settings.

Choose “Site Settings” from the menu and you’ll be shown a list of all the permission set for the current web site.

The dialog shows you the current value of each setting and allows you to clear settings. If you clear a setting, you’ll be prompted again the next time the web site attempts to use the specific feature.

April 09, 2013 03:38 AM

mfinkle, I'm inclined to r- but this is just because I feel we don't know what's actually going on
gingerbread calls "lock" when closing a cursor, but ICS+ does not
mfinkle, ok, then my suspicion was correct: locking db to close a cursor is nonsense
mfinkle, in which case I'd probably only do the close-cursor-in-bg-thread for pre-ics
lucasr, that is even uglier!
mfinkle, it's not cute I agree ;-)
all code must be cute

April 08, 2013 07:17 PM

Here's my hypothesis: Twitter has subsumed RSS.

Pretty much any news site or blogger you would usually want to follow has both RSS and Twitter, and Twitter is just much simpler to use. It's a lot easier to follow somebody on Twitter than it is to add an RSS feed to a web-based aggregator like Google Reader. If you don't use a web-based aggregator you have portability/syncing issues where you have to set up your feeds on individual devices and keep them all in sync. Most importantly, Twitter serves as single notification stream that includes simple messages (tweets) and links to other longer/larger content.

So really, it's Twitter's fault that Google Reader is going away. But they're not the only one to blame. Firefox 4 (IIRC) removed the RSS button, making it that much harder to use RSS. Sure, you can argue very few people used it anyway, so removing it was a good idea, but that doesn't mean it didn't accelerate the downfall of RSS. I think other browsers have also made the RSS subscription flow less easy to use over the last few years.

Ordinarily I wouldn't really care about this, except that I kind of like the open web. Twitter is not the open web. I don't want Twitter to end up as the only way for me to subscribe to content. I fear that Google killing Reader is a sign that RSS use is already dwindling, and unless we act to save it, it will die completely.

Thankfully, the fine folks at Digg are building a Reader replacement, which I think is great. Not because I'll use it, but because it'll help slow (and hopefully reverse) the death of RSS.

It would be cool to see their reader clone (or any other web-based aggregators) take on Twitter directly, by making it as easy to reply/comment on articles as possible, and by having a lightweight way to "tweet" new content directly from the aggregator. For the former, it might be necessary to extend RSS to include things like URLs that accept HTTP POST replies or comments, and to specify the format of those POSTs (yay open standards). The latter will take a bit more architecting, probably requiring your feed aggregator to also be your feed publisher, so that it can insert these "tweets" into your feed along with your blog and/or other content.

I don't exactly know what would work and what wouldn't, and I'm probably the wrong person to be asking anyway since I don't use Twitter. But I do use RSS, and I hope that the only thing that kills RSS is another, even better, open standard.

April 07, 2013 08:12 PM

Last week I attended a community building meetup in Toronto, where I had the opportunity to meet with individuals who are driving volunteer participation across different areas of the Mozilla project. Together we discussed the things our teams are doing to engage volunteers, and we brainstormed ways that we can continue to grow Mozilla. These discussions gave me lots of ideas about what we can do to grow our Firefox for Android community, but most of them boiled down to three main points.

1. Improve communication. The first part of getting involved in a project is figuring out what’s going on. Our team tends to have lots of discussions on IRC and in Bugzilla, which is great if you’re following those channels closely, but it can be hard for a casual observer to keep up. We’re already trying to address this issue with a new mailing list for development discussions, as well as Twitter and Tumblr accounts for more lightweight updates. Mark Finkle just wrote a blog post covering these communication channels in more detail.

2. Diversify opportunities. When newcomers show up, we help them set up a build environment and point them at a list of mentor bugs. This is a great way to get started, but it doesn’t provide a path to becoming a core contributor, or a path toward other types of contributions. I’d like us to encourage more advanced contributions, such as helping debug difficult crashes, or working on bugs that will help us complete a feature we’re targeting for a given release. I also want us to do a better job advertising all the different ways someone can contribute to Firefox for Android, especially testing and support. Our “Get Involved” page mentions some of these opportunities, but there’s probably more we can do.

3. Manage expectations. Even though we do our best to make it easy, writing a patch is hard. New contributors need to remember that it can take a significant amount of effort to get a patch accepted, and core team members need to remember that it takes time for newcomers to develop the knowledge that we often take for granted. We also need to recognize that newcomers are volunteering their time to help improve Firefox, and that mentors are volunteering their time to help grow our community. It’s a lot of work all around, but no one ever said open source software was easy!

April 05, 2013 06:38 PM

Subscribing to Feeds:

Nightly adds support for subscribing to RSS/Atom feeds

April 04, 2013 06:59 PM

Firefox on desktop has nice support for previewing and subscribing to syndication feeds (RSS and Atom). There is even support for creating Live Bookmarks. Firefox for Android does not support anything related to syndication feeds… until now.

We just landed basic support for subscribing to feeds discovered on a web page. This is only initial support, so many things are not supported.

How it works:

• If feeds are discovered on a page, Firefox will enable a menu action on the URLBar long-tap menu. Yes, we have a URLBar long-tap menu!
• Tap the “Subscribe to Page” menu action.
• If there is more than one advertised feed, choose the feed you want.
• Pick the online web service where you want to add the subscription. The choices really depend on the locale, but initially Google Reader (but not for long) and Yahoo are supported.

The limitations:

• We only support online web services right now. We are looking into local application support too, but have not seen a universal way of listing feed reader applications. We are working on a proposal and want to get support from native feed reader apps like Feedly and Newsblur.
• No support for feed previews. No plan to add support
• No support for adding new web service handlers. We are working to add this support.
• No support for Live Bookmarks. No plan to add support.

In pictures:

Long-tap on the URLBar

---

Choose “Subscribe to Page”

---

Choose the feed

---

Choose the web service

April 04, 2013 06:56 PM

Add-on: URL Fixer:

Fixes common typos in URLs entered in the address bar

April 04, 2013 02:47 PM

On The Web

If you want to stay up to date on any new developments in Firefox for Android (Fennec), check out the new Tumblr and Twitter stream. Lots of updates on what’s landing in Fennec Nightly, tips and tricks and summaries of the Mobile Engineering Team meetings.

Mailing List

We have a new mailing list at mobile-dev-firefox@mozilla.org. The newsgroup at mozilla.dev.platforms.mobile is being closed. Use the new mailing list to following along and give feedback on topics being discussed, or post your own ideas.

On IRC

As always, you can jump on Mozilla IRC and talk directly to the Mobile team in the #mobile channel. This is great if you want to start working on the code, need help writing an add-on, want to help investigate a bug or just rant about some design decision.

April 04, 2013 01:17 PM

JavaScript Improvements:

Checkout the latest ARMv7 JavaScript performance improvements

April 04, 2013 12:38 AM

With the recent launch of Firefox 20 for Android, we retired the quit button. Some of you noticed. Some of you were sad. Which in turn made us sad. Here’s how you can get it back, and some background around why we removed it in the first place.

You broke my workflow!

If you used Quit and were unhappy to see it go, well, we’re really sorry about that. The good news is that it’s easy to get back. Just install the QuitNow add-on, which will put Quit right back in the menu where it was.

Easy, right? Now go forth and quit like the wind!

A bit of history

We introduced Quit about 2 years ago, in a time where Android phones were lower in performance, and had poorer memory management built in than they do today. Our users were having memory issues on lower end phones, where Android wasn’t killing background tasks as well as it should have been.

Now, adding a Quit button was kind of a hack that apps aren’t supposed to do. Quitting an app isn’t really a core UI concept on Android, since it handles this kind of memory management at the OS level, and isn’t user controlled per app like on desktop. But we added it in, and our users were happy.

As time went by, phones continued to get faster, and Android improved by leaps and bounds. Android 4.0 brought with it better memory management than before, and also provided users with a multi-tasking interface that also allowed apps to be manually closed, satisfying those who preferred managing apps on their own over simply allowing the OS to make choices for them.

Growing with Android

As these improvements have developed on Android, Firefox has been improving release by release as well. Firefox 20 shipped with Private Browsing, for example. We have lots of other great stuff in the pipeline over the next several releases. A better homepage. A more beautiful Reader experience. Enhancements to Search. And much more.

The thing is, controls to operate these features need somewhere to live in our UI, and Firefox is designed to be as minimal and out of the way as we can make it. We aim to avoid overwhelming people with UI since web content always comes first. So we tuck things into the title bar, into the tab menu, and remaining items go into the Android menu.

This means that from time to time, we need to do a bit of spring cleaning on our UI to make sure we have the most useful, and most commonly used controls at your fingertips.

Given the advances in the Android memory management I mentioned above, it seemed reasonable to remove the Quit button to free up menu UI, and that it wouldn’t adversely affect device performance. The fact is, users simply aren’t faced with the same issues on newer phones that existed 2 years ago. (I should note that we only removed the quit button on phones running Android 4.0+ because of its aforementioned improvements. This means if you are on Android 2.3 Gingerbread or older, nothing will have changed. The quit button will still be there.)

It’s also worth repeating that Quit simply isn’t a core UI concept in Android apps anyway — notice that none of Google’s apps (GMail, Maps, even Chrome, to name a few) include a quit function, nor do must other independently produced apps.

Make it yours

Of course, none of that is meant to convince you that you shouldn’t have a quit button if you truly have a need for one. And that’s what makes Firefox so great: even if a feature doesn’t exist as core functionality in the browser, chances are that an add-on either exists or can be built to satisfy that need. We recognize that everyone uses the internet differently, and we encourage everyone to customize, hack and tweak your way to a better Firefox that works for you. It’s a lot easier than you think, and can make a world of difference to your experience!

April 03, 2013 09:33 PM

Firefox 20 for Android is out and we added a lot of cool features, like customizable home page and private browsing. We also removed some things, most notably the Quit menu.

Android, and most mobile platforms, don’t really support the notion of quitting an application. The OS will take care of killing processes when it needs more resources. Android also has a “Recent Apps” list and allows you to kill an application by swiping the application off the list.

If you really want a Quit menu, try using the QuitNow add-on for Firefox.

April 02, 2013 06:03 PM

Talos

This section tracks Perfomatic graphs from graphs.mozilla.org for mozilla-central builds of Native Fennec (Android opt). The test names shown are those used on tbpl. See https://wiki.mozilla.org/Buildbot/Talos for background on Talos.

tcheckerboard

Simple measure of “checkerboarding”. Lower values are better.

0.23 (start of month) – 0.0 (end of month).

tcheck2

Measure of “checkerboarding” during simulation of real user interaction with page. Lower values are better.

3.47 (start of month) – 3.47 (end of month).

trobopan

Panning performance test. Value is square of frame delays (ms greater than 25 ms) encountered while panning. Lower values are better.

12000 (start of month) – 12000 (end of month).

tprovider

Performance of history and bookmarks’ provider. Reports time (ms) to perform a group of database operations. Lower values are better.

375 (start of month) – 375 (end of month).

tsvg_nochrome

Page load test for svg. Lower values are better.

4020 (start of month) – 4000 (end of month).

tp4m_nochrome

Generic page load test. Lower values are better.

720 (start of month) – 720 (end of month).

tp4m_main_rss_nochrome

95000000 (start of month) – 88000000 (end of month).

Several improvements

tp4m_shutdown_nochrome

28000000 (start of month) – 25000000 (end of month).

This “improvement” is bogus — see bug 797339.

ts

Startup performance test. Lower values are better.

3400 (start of month) – 3800 (end of month).

There is significant noise in this test; it’s not clear if there was an actual regression this month.

ts_shutdown

Shutdown performance test. Lower values are better.

28000000 (start of month) – 25000000 (end of month).

This “improvement” is bogus — see bug 797339.

Throbber Start / Throbber Stop

These graphs are taken from http://mrcote.info/phonedash/#/.  Browser startup performance is measured on real phones (a variety of popular devices).

This month’s graphs are incomplete (end early) but reflect the best data available at time of writing.

“Time to throbber start” measures the time from process launch to the start of the throbber animation. Smaller values are better.

“Time to throbber stop” measures the time from process launch to the end of the throbber animation. Smaller values are better.

Eideticker

These graphs are taken from http://eideticker.wrla.ch. Eideticker is a performance harness that measures user perceived performance of web browsers by video capturing them in action and subsequently running image analysis on the raw result. More info at: https://wiki.mozilla.org/Project_Eideticker

awsy

See https://www.areweslimyet.com/mobile/ for content and background information.

awsy-mobile had a difficult month; we are re-generating the March graph data now. I’m going to skip these graphs this month since they are not quite ready yet.

March 29, 2013 12:28 AM

WebGL Canvas Performance

James landed bug 829747 to improve performance of WebGL canvas updates. It could boost performance by 10%.

Packaged Apps Support

James Hugman landed initial support for packaged apps in Firefox for Android. Packaged apps will allow Firefox for Android to support privileged WebAPIs, giving apps more freedom to access more device APIs.

Keyboard & Gamepad Navigation

Kartikaya has been working to add navigation control for non-touch input systems like keyboards and game controllers. We have been testing on an Ouya game console system. Keep up to date on our status by following bug 831778.

Automated Testing

Chris and Jim have been working to get IME tests into our automated test system. Geoff also landed code to create screenshots from the test device when tests fail. This could make it easier to find the root cause of the failure or just debug intermittently failing tests.

Miscellaneous

Finkle is looking for ways to remove the pageload throbber, which has produced some good feedback. Brian and Nick are closer to a release milestone for their Eclipse integration work. Sriram has been doing more work to reduce the number of views used on the UI layout. Lucas is adding a11y support into the TwoWayView widget.

Full Details

March 27, 2013 08:01 PM

Robocop supports UI testing of Firefox for Android using Robotium. With the changes in bug 854549, Robocop now automatically generates a screenshot when a test fails, so you can see what was happening at the moment the test failed.

I am hoping that this will help diagnose intermittent test failures, especially those that seem to only happen during automated testing.

With these changes, robocop takes a screenshot whenever a test assertion fails or a test throws an exception. It does that with Robotium’s Solo.takeScreenshot(), which simply generates a jpg. Unfortunately, takeScreenshot is confused by our content view: Instead of capturing the displayed web page, it shows a big black rectangle. That’s going to be a big disappointment when debugging some failures, and I hope we can find a solution to this limitation, but at least we can see chrome — and a lot of tests fail on the awesome screen or when interacting with menus or other Java UI elements.

The screenshot jpg is written to /mnt/sdcard/Robotium-Screenshots on the device. To allow this to work on tbpl, the robocop framework pulls the screenshot, base64 encodes it, and dumps it to the log. When debugging robocop failures on tbpl, look for “SCREENSHOT” in the log. You should see something like:

SCREENSHOT: data:image/jpg;base64,/9j/4AAQSkZJRgABAQAAAQABAAD/2wBDAAEB ...

Copy/paste the base64 text to a file and decode it:

base64 -d myfile > screenshot.jpg

And now you can view your screenshot:

firefox screenshot.jpg

This is still a little rough. One of these days I hope we can:

- capture content…maybe use a gecko screenshot?

- display the screenshot directly off of tbpl, similar to the reftest analyzer (see bug 747440)

March 26, 2013 06:07 PM

“So! Many! Views!” — that’s exactly what I felt when we started the process of optimizing Firefox for Android. Compound Drawables was pure magic. It reduced a lot of views in the home page. But we wanted to see where all it could be used. The custom menu was a good choice. To stand out from other menus, but still feel like Android menu, we added the images to the menu. This required re-writing the entire menu management ourselves. Also, some menu items are checkable and some others can have a sub menu. We added an indicator on the right for the same. The final layout had no less than 8 views to manage the image, text and the indicator along with the variable padding in between them.

How do we reduce the views in this menu? This menu is going to exist for the entire life time of the app (at this point of writing, even though they use a list view, the individual rows aren’t cleared every time the menu is closed). To start optimizing, let’s look at how the original menu layout was.

    <LinearLayout>

        <!-- left-most padding -->
        <View android:layout_width="10dp"/>

        <!-- icon -->
        <ImageView />

        <!-- menu item name -->
        <TextView />

        <!-- right Indicator -->
        <FrameLayout>

            <!-- tick -->
            <CheckBox />

            <!-- more indicator -->
            <ImageView />

        </FrameLayout>
        
        <!-- right-most padding -->
        <View android:layout_width="10dp"/>

    </LinearLayout>

The low hanging fruit here is to combine the ImageView for the icon with the TextView. That reduces one of the two views. The left and right most padding are interesting cases. The TextView by itself cannot have a standard margin. This would push the text more inside, if the icon or the right indicator is present, but will look right without them. But, that’s not the intended design. The parent LinearLayout can have a padding. However, this layout file actually had a <merge/> tag as the parent, as the layout could be inflated into any ViewGroup on demand. Now, since the left image is now made a compound drawable, the padding can be merged with the TextView. We are left with the right indicator (3 views) and an empty view for padding.

The interesting thing with compound drawables is that they support states. The state of the TextView is duplicated to the compound drawables too. If there is a way to combine the CheckBox and the ImageView as a single drawable, the entire right indicator could be made a compound drawable. How do we do that? The easiest way is to have custom states. A typical state list for the right indicator would look like:

    <selector>

        <!-- more indicator -->
        <item app:state_more="true"
              android:drawable="@drawable/more_indicator"/>

        <!-- checked state -->
        <item app:state_more="false"
              android:state_checkable="true"
              android:state_checked="true"
              android:drawable="@drawable/check_mark"/>

       <!-- unchecked state -->
       <item app:state_more="false"
             android:state_checkable="true"
             android:state_checked="false"
             android:drawable="@drawable/check_box"/>

       <!-- default state -->
       <item android:drawable="@android:color/transparent"/>

    </selector>

The right side of the TextView is shrunk to a single image with multiple states. This can be the android:drawableRight of the text. So, how many views do we have for the menu item?

    <TextView android:drawableLeft="@drawable/_assigned_by_code_"
              android:drawableRight="@drawable/_right_indicator_selector_"
              android:paddingLeft="10dp"
              android:paddingRight="10dp"/>

And that’s how we optimize Firefox on Android! One view at a time!

March 26, 2013 05:41 AM