Release 0.2 – Contributing to Mozilla

For this release I submitted two patches to Mozilla’s debugger. I found these bugs by looking through the “good second bug” list to try and tackle a couple of harder problems. I ended up submitting two patches. The first bug I fixed was a standard mentored bug meaning that an experienced Mozilla contributor guides and aids you in solving the bug. The second bug was a bit harder to find. I found a broad bug where they instructed contributors to take one directory and make the specified changes since it was a broad bug fix. What was different with this one was I actually had to create and file a bug report my self and link it to the broader bug and see if they will take the patch.

The first bug can be found here: Fixing this bug required moving various pieces of code that are no longer used in Mozilla. Fixing the bug seemed fairly straight forward and it was completed in two steps. The first step was to reduce an API call that is no longer used to a native Javascript solution. The second step was to remove two helper functions that were no longer used. As I was looking through the code I noticed a similar function call that was similar to the API I was removing that the mentor did not mention so I left a comment asking if that should be changed. At the same time I decided to submit my bug fix without fixing the other issue I found just in case it did not need to be changed and this would speed the process up a bit. It turned out the mentor has been busy and this bug isn’t critical so he has still not got back to the request and it is pending for approval. One other hurdle I encountered while fixing this bug was the fact that my mercurial (the version control system Mozilla uses) still had my previous commit from another bug fix I did before. When submitting a bug to bugzilla you issue a hg bzexport command to send your commits to bugzilla. I was unsure if my previous commits would be submitted again so I had to find some commands to undo my commit. This turned out to be a bit tricky as you needed to enable an extension in mercurial. After I enabled this function I was able to roll back the commit and submit my new patch.

The second bug I fixed was here: and is part of a bigger bug which can be found here: The premise of this bug was similar to the previous as it was converting code from one API use to another but it wasn’t as straightforward. The bug required changing¬† used of ‘defer’ to ‘new promise’. What made this more difficult was the fact that new promise had to be implemented in a different way that defer was. Defer was implemented using


followed by

return deffered.promise

Promise was implemented using

return new Promise(resolve =>{ /* more code here */ resolve();}

This meant the code needed to be rearranged to be in the return new promise code block where it was previously above the deferred call. To figure this out I was instructed to read instructions provided in a group message that can be found here:!msg/

The bug fix required me to seek out general instructions and implement them on a directory where I found a potential bug. This was harder as I was not given step by step instructions on what to do and I was not directly told what file or directory I had to fix. This bug fix ended up being more adventurous and in turn was more rewarding to solve.

Fixing bugs in Mozilla has been an extremely rewarding experience. I have had the opportunity to be part of a massive project and got exposure to working with an entire community to create something I could not possibly have created by my self. I got to learn new technologies such as mercurial and learned how to find, file and submit bugs. In the future I plan to keep contributing to open source to get exposure to projects I am interested in and give back to a community that is an integral part of my career.



Continuing with Mozilla

As I dive deeper into open source I am choosing to stick with Mozilla for a few reasons. Firstly I like the layout of Bugzilla making it easy to find bugs that are unassigned, secondly mentored bugs make give you a convenient way of finding someone for help and thirdly I really like the idea of being apart of Firefox, a browser I use every day.

In order to grow during this release I will attempt to do more bugs then I previously took on. I will also try to branch out and try and fix bugs in different branches of Firefox and not the ones I previously worked on.

I considered various python projects but after looking through a few of them it seemed a lot of python projects that were very active were all in machine learning or big data which was not something I wanted to get into while trying to get a foot in the door of the open source world, perhaps in the future I will visit these projects.

The first bug I have assigned so far is here:

To get at least two more bugs done on top of that one I plan to do a bug a week starting now which will give me enough time by the end of the school semester to get my bugs done. To fix the bug above I need to refactor code which is easy enough but there are some questionable lines that may or may not need refactoring, to figure this out I will consult the mentor of the bug.


My most recent addition to my file utility repo written in go was a file. My repo can be found here: Adding a README allowed me to convey a lot of information about my project in an organized manner. README’s are useful for open source projects as they allow people to get familiar with large code bases and look up any relevant information about it. My README includes instructions on how to build, test and contribute to the project as well as how to set up a build environment.

README’s on github have the file extension .md which stands for markdown. Markdown is a way to easily render information. With markdown you can create headers, tables links and many more things that make the presentation of your README easier to understand. I mostly leveraged headers and code blocks to organize my README and display example code. The syntax isn’t too hard to learn and there is great documentation available on it.


Integrating continuous integrating using TravisCI was a rocky experience. It forces you to learn how to compile your program/repo using a build file. My repo was project in goLang. To automatically build a GO program you have to use a make file. After figuring out how to make a makefile work with my program I signed up to TravisCI and added a .travis.yml file to my repo. The yml file defines the version of the language to be used, any dependencies that the project needs, and any scripts that need to be called for building, running and testing the program.

When I first started building my yml file I ran into spacing issues but after that was sorted out every time I pushed to the repo Travis would build and run my project and show me the output of the build. After this I added some test cases for my GO project and added a second command to be run in my travis file. This would run the tests on the project after it was built. I committed these changes and travis successfully built and tested my project.

Before doing this I had not any prior experience with travis and thought this was a pointless and cumbersome thing to set up. After setting it up I realized this was a very useful tool for collaborating projects to continually test any changes made to the repo. I like the fact that in GitHub it shows you if the build was successful or not.

Github repos and pull requests

The language I chose to use in my github repo was GO. Go was an interesting language to briefly learn and had some interesting syntax. Nothing about it was out of the ordinary and I would use it again if I saw the need for it. I chose this language just as a way to get exposure to something I have not used before.

To help with creating one of the functions in my issue tracker I simply looked at GO’s documentation and followed the steps they took. This lead to no licensing issues but there were some technical issues dealing with file paths and building the project while keeping in mind that other users would be working on this code base. I had to make sure to reference the current project directory when hashing a file and made sure to use a file everyone working on this would have access to (the license file).

Contributing to another project was a rewarding experience. I chose a python project as I had experience with python in the past and was looking more into figuring out how to do a pull request then to learn a new language. It was easy enough to make changes to my forked repo and then submit a pull request.

Having users contribute to my project was something I have done before but in the past everyone was a contributor of the repo. The way we did it now was through issues and pull requests. It was fun to help people with issues on the project by communicating through the issue tracker, assigning the issues and reviewing their code in the pull request.

The most important thing I learned as a contributor to another persons repo was to make sure I did my best to not introduce my own coding style to the project but to conform to the style and standards of the project. As a maintainer I learned that it is important to clearly state your style and standards and to include instructions on how to build and run the project to ensure everyone gets similar results.

In using git I ran into issues connecting the pull request to the issue I was solving and learning how to assign people to issues. All of these problems were fixed with experience and research.

Fixing Mozilla

Finding a suitable bug can be a daunting task. Searching github or bugzilla for a new bug that hasn’t been assigned can take some time and a lot of the time that bug might be too difficult for a first bug. Luckily many open source communities leave minor bugs open to help people who are interested in contributing open. These bugs are usually tagged with good first bug and give contributors the chance to learn how to install the environment and get familiar with the review process.

I fixed two bugs that dealt with fire fox. The first bug I found was a mentored bug on the fire fox developer tools. The bug was to change a function call dealing with nodes in the inspector. I needed to change the call to an existing function as well as change the string on the menu to reflect the change. When I first started this bug all the instructions were laid out on how to go about fixing this bug. Naively I thought some of the instructions were unnecessary and went ahead and fixed the bug how I thought it should be fixed. It turns out a massive project like fire fox that is written in many languages has a system in place to make sure when a string is changed in one language, devs who work on fire fox in other languages can be notified of these changes. I submitted my patch using bugzilla and mercurial and was promptly informed that I neglected to follow the steps and would have to edit my patch to propagate the change to devs working in other languages. Luckily the mentor was very helpful and I got more experience in mercurial with changing commits. The process of fixing this bug and the exchanges with the mentor over bugzilla took around three days. Once the commit fixed all of the issues detailed in the bug report the mentor submitted my patch for testing on Mozilla test servers. They provide a link so you can watch the status of your bug as it is being tested. My patch passed all testing and the mentor informed me he would tag the bug for landing and said a code sheriff would eventually come by and push/merge the commit for me. The bug and all the interactions can be found here:

The second bug I fixed was very straightforward. The bug was to remove four lines of obsolete code in the fire fox project. Since I was experienced with mercurial and how to upload patches to bugzilla the bulk of the work on this bug was taken up by updating my fire fox project with the latest commits and rebuilding my project. One thing I noticed was my commit was still in my ‘hg outgoing’ from my last fix. I was nervous that if I used the command ‘bzexport’ to push my second bugs commit to bugzilla it would push my old one. To avoid this I deleted my first commit, I suspect there is a abetter way around this but since I did not push the code my self I was unsure. Perhaps in the future working in a separate branch per bug would get around this issue. The bug this time was simple and did not require testing. I did not have to change my commit as I got everything right the first time. The bug and my interactions with my mentor can be found here:

The mentors at Mozilla are very friendly and helpful. They are a smart group of people and are exceptionally patient when helping beginners. I found it easy to approach them and after fixing my second bug the mentor even gave me a list of ‘good second bugs’ and ways to find more bugs to keep contributing. In the future I want to try working on slightly more complex bugs and possibly on projects on GitHub to get more familiar with making pull requests and pushing my own bugs to repos.

Working on bugs

The bug I was recently working on this week was a bug in the fire fox developer tools. This bug was an update to the developer tools to call a new function to collapse nodes when viewing HTML. The change was to make the collapse function call the collapse all function to recursively collapse all the child nodes of the node you are collapsing. The community so far has been very friendly, helpful and patient as I was making obvious mistakes such as not updating comments. They stayed kind and helped me through every step including testing and uploading.

As I worked on the bug I learned a lot about mercurial, the version control used in the fire fox project. While mercurial is similar to git I am not an expert in either and it has been a learning experience. I was having trouble pulling new versions of fire fox and ended up pulling prematurely and rebuilding my entire project which takes hours on the virtual machine I use.

Mozilla does very interesting things when managing a multi-language large scale project like Mozilla. Since i had to update the string of an item on the menu that would not be translated to other languages. To solve this Mozilla has any changes done to strings be accompanied by a variable name change as well. The reason they do this is so when developers working on the other languages build their project it will fail as their variable does not exist any more. This signals the developers to look at the new variable and apply a translation to ensure the strings are updated across all languages. They also have an online code tester that tests changes done to the project as well as code deputy’s who are responsible for landing code changes to ensure nothing breaks.