Improving <select> dropdowns

9 September, 2016 § 3 Comments

indexLast week marked the beginning of a new 12-week period of mentorship for myself. I’ll be working Mike Conley to share mentorship duties as we mentor a group of five Michigan State University students. The students are all seniors in the Computer Science program.

The MSU Capstone is a program that pairs industry companies with small student groups to give students access to real-world software development and the software development life cycle.

This semester, the five students will be working on improving the visual design of the <select> dropdown. The project has three main components:

  1. The <select> dropdown has two separate implementations: one for single-process Firefox (going away soon), and another for multi-process (e10s) Firefox (the new hotness). The old implementation should be removed, and single-process Firefox should use the implementation that was added as part of the e10s project.
  2. The default look and feel of the <select> dropdown is pretty packed. We want to give more space to the items in the popup to allow for improved readability, as well as making it look more “modern”.
  3. <select> dropdowns have pretty bad usability when the number of items gets very large. They’re also pretty hard to use on touch-screens. The dropdowns should have the ability to filter items and should have more padding when opened via a touch event. The increased padding is intended to make it easier to tap on the desired option as well as to make the options easier to read when they may have a finger hovering over them.
team-photo(left to right) Jared Beach, Fred Luo, Mark Golbeck,
Miguel Wright, Tyler Maklebust

Since the students were assigned to the project last week, they now have local builds up and running as well as Bugzilla accounts. We’ve been active on IRC and will have weekly check-in meetings over Vidyo.

I’ll have more to share in the coming weeks as the students begin ramping up on their work.

Outreachy wrap-up

8 September, 2016 § Leave a comment

pjk5iqnnJust a couple of weeks ago marked the end of my first Outreachy session. During the session I mentored Katie Broida as she worked on some pretty cool features for Firefox.

I learned a lot during the session, and I think she did too. I learned how to advertise and recruit for job openings, gather initial work, and to try to be as attentive as possible for the people that I’m working with.

We started advertising the internship a few weeks before the deadline to apply. Prior to advertising the internship there was little to no outreach to potential applicant pools. In the future, I hope we can reach out to campus groups, hobbyists, and other places that we might find potential candidates. We also need to do this work sooner, as a good number of potential candidates will already have made their internship plans four to six months earlier.

One of the advantages of being an open source company is that Mozilla can help potential applicants get involved in the community far before the application period opens. Applicants can get a chance to see if they will enjoy the work of their internship, and mentors can get a chance to see if the applicants will be successful. This becomes more powerful and insightful than the traditional interview.

As far as Katie’s work, she did an amazing job. Katie fixed numerous bugs throughout the Firefox user interface as well as added a couple new features too. On Windows 10, we now show a larger graphic for the Start Menu tile (it doesn’t work for everyone though, still some ghosts in the shadows here), and for all users we now have a new zoom indicator in the location bar that appears when a site is not at 100% zoom.

Restoring defaults in the Customize Mode now also restores the theme, and she introduced a new API for tab-specific panels to opt-in to closing when the selected tab changes.

Not only did Katie fix a bunch of bugs during the past four months but she also blogged about them, keeping detailed reports about how she got stuck and later how she was able to move around, over, or through the obstacles.

I had a great time working with the Outreachy program and I’ll do it again when Mozilla sponsors another session.

A story of bug fixing

9 April, 2016 § Leave a comment

I spent some time last night looking in to a bug in the Firefox preferences as part of the Outreachy internship I’m mentoring. This bug is about how the context menus in our preferences were squished horizontally compared to normal context menus. I’ve put screenshots of the two below so you can compare.


Looking at bug 1247214, I knew that context menus outside of the preferences looked fine but context menus in the preferences were broken. This meant I had something I could compare side-by-side when looking at the CSS.

I used the inspector and looked at the applied styles for a xul:menuitem and compared them between the preferences and non-preferences. I was surprised to see that they were nearly identical, and what differed was inconsequential.

After walking up the DOM from the xul:menuitem and seeing that the two instances were still nearly identical, I had to think of a different route. Somewhat by chance I realized/remembered that there were children nodes of the xul:menuitem that could possibly be affected. In the Inspector I expanded the xul:menuitem and looked at the rules for the xul:label inside of it. Immediately I noticed that the -moz-margin-start and -moz-margin-end were being set to zero and the rule looked like it wasn’t intended to affect context menus. Unsetting that rule fixed the bug.

So that describes how I found the issue with the bug. Figuring out a fix for it wouldn’t be that difficult now. I also wanted to find what changeset introduced the bug so I could learn more about why it was there.

Using MXR, I pulled up the `hg blame` for the file and went to the offending line. Clicking on the revision number on the left of the line brings up some of the diff from the changeset. At the top of this new page, I clicked on “changeset” to see the full changeset. This unfortunately was a refactoring changeset and wasn’t what actually introduced the offending lines. I then clicked on the parent changeset and based off of that revision found the file again and ran `hg blame` on it. Now the offending line was linked to the changeset that introduced the bug.

After reading through the bug that introduced the changeset I knew that I could safely make this change as the lines were never intended to alter context menus, and I also knew what to look for and test while making the change so I wouldn’t regress the original bugfix.

All of this being said, I probably could have found this quite a bit faster by using a tool called mozregression. mozregression is a tool that will help you run a binary search on all of our nightly builds (continuous integration ones too). As you are likely already aware, binary search is very fast, letting mozregression help narrow down the day that the regression got introduced from a range of 10 years to a single day in about 7 builds.

If I had taken the mozregression route I probably could have saved myself about 45 minutes of debugging and digging around. But both routes work well, and sometimes I learn more from one than the other.

I know this write-up was long, but I hope it was valuable.

Outreachy Internship

9 March, 2016 § 1 Comment

This summer, I with the help of Mozilla, will be mentoring someone as they work on fixing some of the papercuts in the Firefox desktop user interface.

We know there are problems with Firefox when it comes to things “just working right”. Some involve the smoothness of entering and exiting Reader Mode, while others involve the fit and finish of our “getting started” tours.

If you know JavaScript & CSS and are looking for a summer internship, you can be the person that I mentor.

This is a paid internship and will run from May 23rd to August 23rd, 2016. A $5,500 stipend will be provided as compensation for the internship.

This internship is open to under-represented groups in the free and open-source software community. These groups include all women (cis and trans), trans men, and genderqueer people internationally, as well as all Black/African American, Hispanic/Latin@, American Indian, Alaska Native, Native Hawaiian, and Pacific Islander people in the US.


The ideal student will have the following background and availability:

  • Available to work on the project about 40 hours per week. This will not be a good project to work on while taking part in another internship program at the same time.
  • A strong CSS background. Do you feel comfortable answering how the CSS box model works, and the order that elements are painted to the screen?
  • A strong JavaScript background. Have you used JavaScript Promises before? Do you know the difference between bubbling and capturing event listeners?
  • Not afraid to work with some C++ if necessary. Fixing some of the bugs below may require working with some of the Windows-specific platform widget code, and this is almost entirely written in C++. It’s not that scary, but has different nuances than the JS/CSS work.
  • A productive work environment. Students in this internship will be “working from home” and will need to provide their own working environment.

Finding your way around

You’d mostly be writing JS and CSS, though being comfortable with the other technologies we use will be helpful.

To get a feel for things, you can open up the Browser Toolbox and “inspect” the UI of the browser. From there you can use MXR ( to go from searching for some text on a button you see in the user interface to finding the code that is executed when the button is clicked.

Set up an “artifact” build. This is the simplest build setup that we have for Firefox, and should take less than 10 minutes. Once you’re up and running, you can use this artifact build to make changes to the JS & CSS of the browser.

Getting Started

I’ve put together a list of bugs that will be the focus of this internship. People wanting to apply to this should pick a bug off of the following list and begin working on it.

Each bug on the list has a number of “points” that are assigned to them. The more points a bug is worth, the harder the bug may be to get fixed.

There’s currently nine bugs on the list, but I may add more in the future when these get fixed.

Here’s the link again to the bug list: Go ahead, click on it, look for a bug that excites you, and see how you can use the tools from the “Finding your way around” section to fix the bug.

Interested and have questions?

Please reach out to me. I’m available via IRC during the US Eastern timezone (+5 GMT) working hours on irc:// in the #fx-team channel by the name of `jaws`. You can also email me at `jaws [at] mozilla [dot] com`.

More information about the Outreachy program can be found on the Mozilla wiki page, as well as the Gnome wiki page (the originators of the Outreachy program).

Polishing Firefox for Windows 10

22 July, 2015 § 12 Comments

Over the years, the Firefox front-end team has made numerous polishes and updates to the Firefox theme.

Firefox 4 was a huge update to the user interface of Firefox compared to Firefox 3.6. A couple years down the line we released Australis in Firefox 29. Next month we’ll be releasing Firefox 40 and with it will come with what I believe to be the most polished UI we’ve shipped to date.

The Australis release was great in so many ways. It may have taken a bit longer than many had expected to get released, but much of that was due to the complexities of the Firefox theme code. During the Australis release we removed some lesser used features which consistently were a pain in the rear when making theme changes (small icons and icons+text mode, I’m looking at both of you 👀).

Now with Firefox 40, we’re able to show the benefits of our refined theme code and our ability to ship updated and modern themes much faster than ever before.

With Firefox 40 on Windows 10, which you can download today using the Firefox Beta channel, we’ve matched the tabstrip and toolbar to the native Windows 10 theme. This includes refinements to our standard icon set, as well as much improved HiDPI (>1dppx) support. All of our first-tier icons now have 2× variants that are shipped with the browser, and the remaining icons buried in the depths of the browser should be fixed soon as well.

My favorite feature of Firefox on Windows 10 is the increased URL and search bar height (pictured above). This is actually something that we’ve wanted to do for a couple years. Firefox has continually had a pretty small font-size for the URL bar, one which makes it hard for users with poor vision to read. The text in our URL and search bars is now on-par with competing browsers. It may not seem like a big deal to most, but it is the small cuts like these that can either add up to cause death by a thousand wounds or be part of the stitches in a bullet-proof product.

Cheers 😊

Default Browsers and Windows 10

18 July, 2015 § 20 Comments

Microsoft is set to release Windows 10 pretty soon and with it comes a new way to set the default browser for your system.

Previous versions of Windows had an API that allowed applications to set themselves as the default application. This worked well and allowed web browsers like Firefox and Chrome to have a single click within their interface to set themselves as the default browser. No extra work was needed by the user after clicking the button within the respective app.

Starting in Windows 10, references to this API now generate the following error dialog on the machine:


Obviously, this message isn’t that helpful. First, users who click on a button to “Make Firefox my Default Browser” now get a dialog telling them what to do instead of doing it for them. Secondly, the message is given in a prompt that blocks interaction with the rest of the computer until the OK button is clicked. Combining this second issue with the lengthy list of steps that the dialog provides makes the situation even worse, as the user will have to memorize this 3-step process before clicking OK.

This experience isn’t something that we want to ship to Firefox users. When I first saw this experience, I sent an email to some people working on Chrome to ask them what their plans were to solve this. They said that they had looked in to this and decided they would instead just open the Settings app to the Default Applications view.

Settings app

I brought this approach back to some of my coworkers and we decided we would match the behavior that Chrome was using. After all, it didn’t seem like a better solution existed and we certainly didn’t want our users to be seeing the ugly dialog described above.

After I landed the changes in Firefox to open the Settings app, Masayuki Nakano provided an alternative implementation that would open a friendlier looking dialog to set the default application.

Alternative approach

This dialog looks a lot better, but it only sets the choice as the default browser if the small “Always use this app” checkbox at the bottom is checked before the OK button is clicked.

Once we had two implementations, we ran an A/B test of them for a week with our Nightly audience.

Key Count Percentage set as Default
Alternative Approach/OpenAs (users who did not set the browser as default) 2.35k 53%
Alternative Approach/OpenAs (users who did set the browser as default) 2.65k
Settings (users who did not set the browser as default) 2.76k 50%
Settings (users who did set the browser as default) 2.86k

The table above shows the data that was collected through the A/B test from June 22 to June 29 with Firefox Nightly 41. This data showed that 53% of alternative-approach users set Firefox as default, whereas 50% of the Settings-app users set Firefox as default.

With only a week of data, we didn’t see a statistical difference between the two approaches and decided we would stick with the Settings app due to it’s wider adoption. We also had issues with the OpenAs approach where we weren’t able to register all protocols and file extensions.

Next Steps

The default browser situation on Windows 10 is pretty bad. There is more work that we can and should do in the Windows 10 upgrade experience to retain users (the default upgrade changes the default browser to Edge).

We also would like to improve our telemetry tracking of the default browser dialog. Ideally we could use some accessibility or automation APIs to scroll into view the Default Browser option within the settings app (it’s scrolled out of view when it is first opened).

Final In-content Preferences status update

6 May, 2015 § Leave a comment



We are now a week away from the release of Firefox 38, and with it will finally come the release of in-content preferences. You can download Firefox Beta today to see what it will look like when it hits Release next week.

I want to give a huge thanks to all of the people who worked on the project. You all helped it get to the point where hundreds of millions of people will get to see a refreshed and modern preference experience.

Major thanks goes out to Stephen Horlander, Michael Maslaney, Madhava Enros, Gijs Kruitbosch, Blair McBride, Richard Marti, Tim Nguyen, Justin Dolske, Zhenshuo Fang, Dão Gottwald, Tim Taubert, Matthew Noorenberghe and a huge host of other people that have helped.

Known issues:
1) Dialogs opened in the Advanced pane don’t use the same tab-modal dialog implementation that can be found within the rest of the preferences. We hope to get this fixed in a future release very soon.
2) The design for focus rings within the preferences still has a refresh coming, but it won’t make Firefox 38. As with #1, we hope to get this in to a future release very soon.
3) If you have gone to about:config and set to `false`, the Search pane of the preferences is broken. The fix for this didn’t make the 38.0 cut-off, but it will be fixed within the next few weeks following release. Going forward this preference will be removed, so now may be a good time to revert that preference back to `true`.

Other lower-impact known issues can be found on Bugzilla.

You can download Firefox Beta today to see what it will look like when it hits Release next week.