Margaret Leibovic

New Coding Stewards Mailing List

Wed, 15 May 2013 14:18:00 -0400

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!

Dominant Favicon Color, Revisited on Android

Wed, 08 May 2013 14:37:00 -0400

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.

Building the Firefox for Android Community

Fri, 05 Apr 2013 14:38:44 -0400

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!

Hacking Firefox OS Apps with Github Pages

Tue, 05 Feb 2013 17:26:09 -0500

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.

Bugzilla 101

Fri, 30 Nov 2012 14:45:00 -0500

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!

Challenges Getting Started with Gaia

Wed, 03 Oct 2012 19:53:00 -0400

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!

How I manage my bugmail with gmail

Fri, 21 Sep 2012 18:39:00 -0400

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!

Recap of Mobile Add-ons Session at MozCamp EU

Wed, 12 Sep 2012 11:45:11 -0400

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!

Text Selection in Fennec Native

Wed, 20 Jun 2012 11:25:00 -0400

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!

This past week the Firefox front-end team had a work week in...

Sun, 29 Apr 2012 12:28:00 -0400

This past week the Firefox front-end team had a work week in Toronto, and had the chance to give a lightning talk about the new Fennec Native UI. This talk is geared towards developers who are already familiar with working on desktop Firefox, but it will give anyone a quick overview of how our mobile front-end is built. I also made the slides available, since they include some links.

Update: Here’s a direct link to the video.

I'm on the mobile team!

Thu, 29 Mar 2012 13:01:00 -0400

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.

Larger Site Icons

Tue, 26 Jul 2011 17:21:32 -0400

Recent mock-ups for the home tab, new tab, awesome bar and full screen mode all call for larger site icons. Although I wrote some code to expand a 16x16 favicon using the icon’s dominant color, a larger icon specified by the site would really be ideal.

The HTML5 spec for link type “icon” describes a sizes attribute, which enables web authors to specify multiple icon sizes. I was curious if anyone was already using this attribute, so I wrote a python script to inspect the 1000 most-visited websites, as reported by Google. Unfortunately, I found that only one website is using this sizes attribute. However, that’s not too surprising, considering this is a new spec that doesn’t seem to do much for websites right now.

I was also curious about how many websites specify link type “apple-touch-icon”, which is a way to specify a larger icon for iOS app shortcuts. I found that 81 of these top 1000 websites include these tags. However, I realized that smart websites would probably only provide this icon for users on iOS devices, so I decided to modify my script to spoof an iPhone user agent header. When I made this change, I found that 225 of these top 1000 websites included an apple-touch-icon.

Based on this data, I’d say that if we started including larger icons in the Firefox UI, icons that web authors can provide according to the HTML5 spec, plenty of websites would be willing to include larger icons in their link tags.

A handful of websites, such as pandora.com and amazon.com, are already including multiple icon sizes in their favicon.ico files, even though they are not communicating this with a sizes attribute. Unfortunately, even if they included a sizes attribute, we don’t currently have platform support for getting multiple icon sizes out of ICO files. However, work is being done there, so hopefully we will be able to use these larger icons in the near future.

The data from my investigation, including a JSON mapping of site URLs to icon URLs, is available here: http://margaretleibovic.com/iconscrape/

Dominant Favicon Color

Thu, 09 Jun 2011 12:35:00 -0400

Most websites only provide a 16x16px favicon, but what can we do if we want a larger icon to represent a site? Faaborg had an idea to use the dominant color of this favicon to color the background of a box surrounding the icon. Yesterday I used the canvas API to prototype this idea for a new tab page, and it turned out pretty well!

I generalized my dominant color function a bit and posted it in a gist, in case anyone else might find it useful! You can also grab the latest UX branch nightly build if you want to see this new tab page prototype in action.

Update: Mardak wrote a neat restartless add-on that lets you test this algorithm (or any variation you come up with) on images on the web.

Managing Your Relationship with Sites

Thu, 26 May 2011 18:32:00 -0400

This post is co-written by Margaret Lebovic and Sid Stamm. This article is cross-posted on Sid’s blog.

As the web becomes more and more complex (and AWESOME), it’s important that you can manage your relationship with the variety of sites out there. Sure, Firefox 4 has a Page Info dialog that lets you control what a web page is allowed to do, including whether you want to let it store data on your computer, access your location information, open pop-up windows, and on and on. However, this dialog only lets you manage your relationship with the one page you’re currently visiting, not the entire set of sites you visit on the web.

We think it’s important to be able to manage your whole relationship with web sites in an intuitive way, and that’s why we’re exited to show you what we’ve started working on: a site-based permissions interface.

This feature is still experimental, but you can give it a shot. In the future, we’ll be putting some polish on the UI, adding more controls like “always access securely” (HSTS), and hopefully giving you a better view of what a site knows about you. We also want to integrate this permissions manager with the site identity block in the location bar for quick and easy access.

Try it out! Grab an Aurora build and try out the feature by typing about:permissions into the location bar.

Identity Block Uplift

Wed, 20 Apr 2011 01:41:06 -0400

In tomorrow’s Nightly build, you will notice the site identity block is sleeker looking than it was before! And it’s extra sexy if you encounter a popup notification!

Shout-out to Stephen, Frank, and Dão for working on this with me.

Do Not Track is more discoverable!

Wed, 13 Apr 2011 15:55:12 -0400

If you get on the new Aurora channel, you will see that the Do Not Track preference is no longer buried under Advanced preferences. Now it’s located at the top of the Privacy pane, so it’s easier to find and easier to let advertisers know that you don’t want to be tracked!

New Blog!

Wed, 09 Mar 2011 17:01:00 -0500

Following in Paul’s footsteps, I’ve decided to set up a blog on tumblr. I’ve been wanting to do a better job of sharing the things I’m working on, and I plan to use this blog to do exactly that. Look forward to lots of sweet screenshots of Firefox 5 features and beyond!

Lifehacker: First Glimpse at Firefox 5’s New Looks and Features

Thu, 17 Feb 2011 11:07:00 -0500

Lifehacker: First Glimpse at Firefox 5’s New Looks and Features

A Month at Mozilla

Mon, 20 Sep 2010 04:00:00 -0400

It’s only been a month since I joined Mozilla as a full time employee, but it feels like it’s been much longer. Joining the Firefox team late in the Firefox 4 development cycle meant diving into a pile of blockers, so I had to get up to speed right away. By the end of my first week, I was the assignee on five blockers, wrote a few patches, and even broke the tree! I couldn’t remember everything I’ve done this past month, so I had to search through bugzilla to jog my memory. It turns out I did a lot! I was able to group most of the larger bugs I worked on into a few categories:

About window: I refreshed the “About Firefox” window to include language about the Mozilla mission, important links, and update functionality. Compare a screenshot of the old about window…

…to a screenshot of the new one!

(bugs 579547, 571127, 571424, 585475, 591013)
Doorhanger notifications: Continuing work that Frank Yan started, I converted the “Remember Password” and “Change Password” notifications from bar-style notifications to doorhanger notifications. Compare a screenshot of an old notification…

…to a screenshot of a new one! (Please note that the styling of these doorhanger notifications is being handled by separate bugs.)

(bugs 567814, 573536, 588309, 594572)
Progress lines: I added progress lines to the location bar and tabs, eliminating the need for the progress bar in the status bar. (The styling on these lines is also being handled in follow-up bugs.)

(bugs 544818, 578028)

Besides these bugs, I also worked on implementing a quick prototype of a “Share” menu to replace the “Send Link…” menu item with a list of sharing services (bug 588508). There are some tricky decisions to be made about how we’ll generate this list of services, so this feature isn’t going to make it into Firefox 4, but look out for it in future releases!

New about:me Page for Firefox!

Mon, 17 Aug 2009 04:00:00 -0400

This summer I created an experimental prototype of an about:me page for Firefox, and I am proud to announce that it is now available for download as an add-on on addons.mozilla.org! The goal of the about:me page is to give you a more interesting view of statistics about your browser usage, providing a fun way to see personalized patterns in your interactions with Firefox. The current version includes graphs that illustrate trends in your browsing and downloads histories. The “Activity Stats” section graphs the websites you visit most, including the individual pages you visit most within each top-level site. This section also graphs your hourly browsing activity, which can reveal patterns in websites you visit most at various times of the day.

The “Downloads Stats” section illustrates the distribution of different types of files you download, as well as daily trends in your download activity.

I plan to continue to develop the about:me page to include more sections from our brainstorming list, such as statistics about bookmarks and tabs. Please let me know if there’s anything you would love to see next!