Margaret Leibovic

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.

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!

This past week, a few members of Firefox team were asked to help out with the big pile of bugs blocking the initial release of Gaia, the Boot to Gecko user interface. I’m no stranger to jumping into a new project, so I figured this would be a fun opportunity to do something different for a few months. I ran into some problems getting my Gaia development environment set up, and I wanted to document them in an effort to improve the experience for other new contributors.

This being Mozilla, the first thing I did was find the wiki page about getting a build environment set up. I don’t have a B2G device yet, so I was looking to set up a desktop development environment. The “quick start” instructions said that I just needed to clone Gaia from github, and then I could run it in a desktop Firefox nightly build. Sounds simple!

git clone git://github.com/mozilla-b2g/gaia
cd gaia
make && /path/to/nightly -profile `pwd`/profile -no-remote http://system.gaiamobile.org:8080

However, when I tried doing that, I ended up with an empty home screen.

I saw that the wiki also mentioned I could download a desktop B2G build, so I tried that next.

/path/to/b2g -profile `pwd`/profile

I still ended up with the same blank home screen. On IRC, I heard ttaubert say he was using his own B2G desktop build, built from mozilla-central. Since I already had a mozilla-central development environment set up, building B2G was as easy as creating a new mozconfig.

cd /path/to/mozilla-central
MOZCONFIG=mozconfig-b2g make -f client.mk build
cd /path/to/gaia
/path/to/my-b2g -profile `pwd`/profile

And that worked! Time to start hacking. I looked through the list of “mentored” github issues, and I found an simple-looking bug in the browser app. The first thing I wanted to do was add some logging in a file. To enable console logging, I heard on IRC that I needed to be running DEBUG=1 make in my gaia directory, not just plain make. I made that change, but this time when I launched my B2G desktop app, I got a completely blank white screen!

There were no error messages in my terminal window, but I learned that I could use the -jsconsole flag to open the JavaScript console. When I did that, I saw some errors in core B2G code.

Error: NS_ERROR_FAILURE: Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIServerSocket.init]
Source File: chrome://browser/content/shell.js
Line: 518

Error: TypeError: CustomEventManager is undefined
Source File: chrome://browser/content/shell.js
Line: 171

No one on IRC in #gaia was able to help me figure out this issue, and I was feeling pretty frustrated. I ended up talking to a B2G developer in the office, and he said that Gaia’s debug mode is often unstable. He suggested that instead of running Gaia in debug mode, I should make a debug B2G build and use dump statements for my print-based debugging. Following this suggestion, I finally ended up in a place to try to start making a patch. However, the instructions for running Gaia’s unit tests say you should be using debug mode, so I don’t know if this is a real long-term solution.

I haven’t finished my patch yet, so I may run into more issues along the way, but I want to encourage developers to update documentation regularly, and to make sure that documentation works. I’m employed by Mozilla, so I’m required to have the patience to sort through issues like these, but they can be a real hurdle for volunteer contributors to get involved in the project. Let’s try to fix that!

This past weekend I attended MozCamp EU in Warsaw, and it was really energizing to see so many awesome Mozilla contributors come together. The theme of this MozCamp was “Mobilize Mozilla”, and I co-hosted a session about developing add-ons for Firefox for Android.

In the first part of this session, we walked through the basics of developing a simple restartless add-on. After that, we set developers loose to start hacking on their own add-ons, encouraging them to start with a bootstrapped add-on skeleton. Before long, we saw a bunch of excited developers pointing to test menuitems and notifications appearing on their phones, followed by discussion about all the cool things they wanted to build. This was one of my favorite parts of MozCamp!

Although this session proved that it’s not too hard to get started with mobile add-on development, there are definitely some pain points. Here are some things we need to work on:

• Create an easier workflow for getting an add-on from your development machine to your phone. Right now the easiest way to do this is using adb, but some developers want to be able to test their add-ons without installing the Android SDK.
• Fully support using the Android emulator to develop mobile add-ons. Some of the developers attending the talk didn’t own Android phones; we had extra phones on hand to lend to them, but that’s not a long term solution. I know that work has been done to run Firefox in the emulator, but I don’t know of anyone on the mobile team actively testing this to make sure it always works.
• Better documentation! This is always true of everything, but I want to call it out. In particular, I think we need more documentation about manipulating content from mobile add-ons. Even though this is very similar to what you would do for a desktop add-on, getting at the content window is different, and this confused some developers.

I’m looking forward to seeing more mobile add-ons, and I’d like to know if there’s anything else we can do to make it easier to develop add-ons for Firefox for Android. The mobile team is always hanging out in #mobile on irc.mozilla.org, so please jump in there if you have any ideas, or if you need help developing your add-on! 

I finally landed basic support for text selection in Fennec Native, and you can check it out in the latest Nightly build! Similarly to how text selection worked in XUL Fennec, you can long tap on some text to start a selection, and use draggable handles to change the selection area. A single tap inside the selection area will copy the selected text to your clipboard, and a single tap outside the selection area will cancel the selection.

There are definitely still a lot of known issues to work out, including full support for RTL pages, support for selection in inputs, and some problems with the handles. Text selection bugs are being marked as blocking bug 695173, so that’s where you can follow our progress. That’s also where you can file the bugs we haven’t found yet!

For the past few months, I’ve been spending most of my time helping the mobile team with the Fennec NativeUI rewrite, and a few weeks ago I officially became a member of the mobile front-end team. Although working on a native Android app has been painful different, I’ve found my desktop browser knowledge to be really useful, especially when working on Fennec features that I also helped make on desktop Firefox. I’m hoping that this will encourage the desktop and mobile teams to work together more closely, since we’re really just all part of a bigger team trying to make an awesome Firefox experience across all of your devices.

I’ve neglected to blog about the mobile work I’ve been doing these past few months, but I’ll use the excuse that I was too busy writing code instead! Among other things, I’ve been working on click-to-play plugins, doorhanger notifications, site settings, bookmarks, and our form assistant UI. Grab a Nightly build to see our most recent changes, or check out Aurora for a more stable experience.