A story of bug fixing

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.

On volunteer and internship opportunities at Mozilla

About a month ago on a flight from Seattle to New York I met a lady who said that her son was studying computer science. I told her about the work that is being done at Mozilla and how we have a lot of opportunities for people who want to contribute to one of the world’s largest open source software projects.

Today I got an email from her son asking about internship opportunities. Her son is just getting started in computer science and has yet to take his introductory courses in CS. There are many people that are in his position and I believe that they can still contribute to Mozilla and gain valuable experience for their future. Below is my response to him:

Hi ____,

Thanks for the email. It was a pleasure to meet your mother on the flight.

Internships at Mozilla require a solid CS basis and will probably be too challenging to undertake before completing your introductory courses. However, that doesn’t mean that there is nothing that you can do at this point. With a basic understanding of HTML, CSS, and JavaScript, there are probably a number of bugs that you could fix today within Firefox.

I would recommend that you spend time this summer, either the whole summer or a period within, as a volunteer contributor to Mozilla. Many of our interns and full-time employees contributed to Mozilla or other open source software projects before joining Mozilla. There are two major benefits for doing so: familiarity with the project and what type of work people do; and practicing the skills necessary to succeed during an internship or full-time role.

I understand that volunteering can present its own time and financial challenges as it is unpaid, but one of the benefits of volunteering is that the work can be done at your own pace and on your own schedule.

You can take a look at the following bugs if you would like to see what the type of work may look like:
https://bugzilla.mozilla.org/show_bug.cgi?id=1026679
https://bugzilla.mozilla.org/show_bug.cgi?id=1043257

As you contribute, more responsibilities will be given to you and you’ll feel confident working on larger tasks.

Let me know if you are interested, and I will find some bugs that are available for you to fix.

Cheers,
Jared

That offer at the end of the email is not something that people can only get by bumping in to me while traveling. If you are reading this blog post and you would like to learn how you can contribute to Mozilla, please join the #introduction channel on irc.mozilla.org and ask how you can get started. Be patient however, it may take a couple hours to get a response from someone due to timezones and busy schedules.

We knew unicorns could bounce, but now they spin?!

One of the hidden features of Firefox 29 was a unicorn that bounced around the Firefox menu when it was emptied. The LA Times covered it in their list of five great features of Firefox 29.

Building on the fun, Firefox 32 (released today) will now spin the unicorn when you press the mouse down in the area that unicorn is bouncing.

The really cool thing about the unicorns movement, both bouncing and spinning, and coloring is that this is all completed using pure CSS. There is no Javascript triggering the animation, direction, or events.

The unicorn is shown when the menu’s :empty pseudo-class is true. The direction and speed of the movement is controlled via a CSS animation that moves the unicorn in the X- and Y-direction, with both moving at different speeds. On :hover, the image of the unicorn gets swapped from grayscale to colorful. Finally, :active triggers the spinning.

Animating and transitioning display:none elements

The current release of Firefox introduces a nice animation when opening and closing the Find bar. Upon opening the Find bar, the toolbar fades in and slides up. Exiting the toolbar will make it fade out and slide down.

As you may or may not know, the user interface for Firefox is implemented using XUL+HTML/CSS/JavaScript.

We use the XUL hidden attribute, which is very similar to the HTML5 hidden attribute, to hide the Find bar when it is dismissed. The presence of the hidden attribute sets display:none on the referenced element. If you’ve ever played around with CSS Transitions or Animations, you’ve probably noticed that display is not a transitionable property.

To maintain add-on compatibility, as well as code simplicity, we wanted to keep using the hidden attribute. Doing so also allowed us to leave the JavaScript unchanged.

This poses a hard problem. If display is not transitionable, how could we animate the behavior here? It turns out that visibility is a transitionable property.

The various states of visibility are atomic. There is no defined behavior for what should happen when an element transitions from visibility:hidden to visibility:visible or visibility:collapse. However, we can use a zero second duration to make the change happen at the instant that we want.

This brings us to our solution:

findbar {
  transition-property: margin-bottom, opacity, visibility;
  transition-duration: 150ms, 150ms, 0s;
  transition-timing-function: ease-in-out, ease-in-out, linear;
  margin-bottom: 0;
  opacity: 1;
}

findbar[hidden] {
  /* Override display:none to make the transition work. */
  display: -moz-box;
  visibility: collapse;
  margin-bottom: -1em;
  opacity: 0;
  transition-delay: 0s, 0s, 150ms;
}

To explain how this works we’ll start by looking at findbar[hidden], since it’s the default state for the Find bar.

When it is hidden, we will force it to be displayed (using display:-moz-box, which is an internal-to-Gecko display value, you could replace this with display:block or display:inline as needed). We then set visibility to collapse, which will effectively make the element invisible and also not consume any space (except for margins, which is important here). We then use a negative margin-bottom to force the element to be placed just out of view of the browser window. Setting opacity here is used to fade the element in and out. I’ll describe the transition-delay last.

When the Find bar is shown, we set margin-bottom to zero which will slide the toolbar up. We also set opacity to one which will make it fade in. The opposite happens in reverse when the Find bar is dismissed.

The key here is the transition-delay that is set in the findbar[hidden] case.

When the Find bar is hidden and transitions to being visible, we don’t have a transition-delay applied. This causes the visibility to change immediately at the beginning of the animation. The Find bar becomes visible and then it slides and fades in to view.

When the Find bar is visible and transitions to being hidden, we delay changing the visibility until the margin and opacity transitions have completed. Running the visibility transition immediately in this case would cause the element to disappear instantly, which would ruin the animation.

That explains how I implemented the Find bar transition in Firefox without affecting themes or having to change JS. It’s a pretty cool technique for showing and hiding elements, and has opened the doors to implementing some other types of animations in the Firefox user interface. Let me know what you think! 🙂

Update: I’ve been told by Frank Yan that this won’t work on non-XUL content since display:-moz-box is needed to get the visibility:collapse to work as needed. Still a cool technique to see!

CSS tip: Creating an elliptical gradient in a square container

Creating an elliptical background gradient in a square container isn’t the most straight-forward in CSS. This is simple to do if you can change the shape of the container, but requires using a separate CSS property to change the shape of the gradient.

To change the shape of the radial gradient, you can use the background-size property to change the bounding box of the background-image.

div {
  width: 200px;
  height: 200px;
  background-image: -moz-radial-gradient(center, closest-side, red, blue);
  background-color: violet;
  background-repeat: no-repeat;
  background-position: center;
  background-size: 100px 200px;
}

See the page on background-size at MDN for more information.