Margaret Leibovic

As part of the Grow Mozilla effort, the coding stewards have been working to grow our coding community. Our main focus has been to increase the number of contributions to the core mozilla-central codebase, which includes making it easier for newcomers to get started, as well as keeping existing contributors engaged. Recent work has been focused on things like mentored bugs and recognizing contributors.

We hold open weekly meetings every Wednesday to discuss progress on these goals, but we want to give more developers the opportunity to get involved with this effort, so we created the coding-stewards@mozilla.org mailing list for broader discussion. If you’re interested in growing our coding community, but you might not be interested in another weekly meeting, please join the list!

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!

While planning a workshop for Dare2BDigital, a technology conference for young women, Lukas and I were looking for an easy way for girls to edit and test their own Firefox OS apps. We were trying to think of where we could host these apps when we decided to try using Github pages.

I’d never actually made a Github page before, but I learned it’s as easy as making a magically named “gh-pages” branch in your repo. To experiment, I decided to test this out on a simple wallpaper app I’ve been working on.

$ git checkout master
$ git checkout -b gh-pages
$ git push origin gh-pages

And voila! My app showed up at http://leibovic.github.com/mural/. This seems great for development because you can just push changes to the gh-pages branch to update a hosted app. But as a bonus for our workshop, we found you can easily modify the app by hitting the “Edit” button at the top of a file on Github, then committing your changes through the web interface.

Note: After the first push it can take up to 10 minutes for the page to appear. So be patient.

While helping new contributors start hacking on Firefox for Android and Firefox OS, I’ve realized that getting comfortable with Bugzilla is a really important part of getting ramped up. Over the years, people have come up with various tips, tricks and tools for making Bugzilla easier to use, and I thought it would be helpful to gather those into one handy blog post!

To start, if you’ve never used Bugzilla before (or even if you have), you should watch a video johnath made called “Bugzilla for Humans”. It gives a nice overview of key Bugzilla features, as well as tips for more advanced users.

After that, you should watch beltzner’s quicksearch video to get a more familiar with Bugzilla’s quicksearch feature. In your browser, you should add a bookmark keyword to search for bugs from your location bar. You can also add Bugzilla to your list of available search engines in your search bar. For a complete list of things you can do with quicksearch, check out the quicksearch reference on Bugzilla.

If you find yourself interested in a certain area of the Mozilla project, you can opt to watch its Bugzilla component. You can also watch certain users, which is a neat feature if you’re a new contributor looking to follow the activity of a more experienced developer. If you’re a new contributor working on a mentor bug, you should watch your mentor to see what he or she is up to! If you start watching components you’ll definitely want to set up some sort of filter to handle your bugmail. For inspiration, you can see what other Bugzilla users have done to handle their Bugmail.

Because Bugzilla has a REST API, people have made tools on top of Bugzilla to make certain tasks easier. For example, there are tools to file new bugs, track a user’s bug activity, and find mentored bugs. There’s also a Firefox add-on that modifies Bugzilla itself to make things easier.

Last, but not least, you should read Bugzilla’s etiquette guidelines to understand what behavior is expected of Bugzilla users. In general, just be a nice person and everyone will be happy!

This is just a quick overview, but if anyone out there has more helpful tips, please share them in the comments!

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!

It seems like most developers at Mozilla have their own optimized bugmail workflow, but today a conversation on IRC inspired me to share mine.

I created a set of gmail filters to group my bugmail into buckets of varying importance. Although gmail doesn’t support filtering based on email headers, I found that string matches do a pretty good job (since most people don’t write things like “You are the assignee for the bug” in a bug comment).

Here’s how I group the things I care about:

Matches: from:(bugzilla-daemon@mozilla.org) subject:((review requested:) OR (feedback requested:))
Do this: Skip Inbox, Apply label “b:review”

Matches: from:(bugzilla-daemon@mozilla.org) “You are the assignee for the bug.”
Do this: Skip Inbox, Apply label “b:assigned”

Matches: from:(bugzilla-daemon@mozilla.org) (“You are on the CC list for the bug.” OR “You reported the bug.”) -{“You are the assignee for the bug.”}
Do this: Skip Inbox, Apply label “b:cc”

And here’s how I catch everything else:

Matches: from:(bugzilla-daemon@mozilla.org) -{“You are on the CC list for the bug.” OR “You reported the bug.” OR “You are the assignee for the bug.” OR “review requested:” OR “feedback requested:”}
Do this: Skip Inbox, Apply label “b”

This is how I can get away with watching the whole Firefox for Android component, but still make sure I see important bugmail in a timely fashion. It’s especially excellent for post-vacation catch-up!

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!