This is a pull request blog post. Please see my blog post on Mozilla devtools-html/debugger.html for more information about the project.
What’s the bug about?
The current implementation of “quick open”, a command pallet like feature in the debugger tool uses bolded black text to highlight words that fuzzy match letters the user has typed into the quick open search box. However, when an item is selected, the current visual aesthetic of the item’s text does not conform to Mozilla products such as Firefox where the text on a selected item appears white and fuzzy matched letters as bolded white text.
At the direction of @violasong, a Mozilla UI designer, the goal is to make the fuzzy matched letters appear bolded white.
Fixing the bug
The first step to fixing a bug for any opensource software is to fork the repository. Then, clone the forked repository onto the local machine and create a new branch:
git checkout -b issue-5679
The second part is being able to work through all of its dependencies and have the application compile and run. The repository has very extensive information regarding the setup of the application. Once setup was complete, go ahead and explore the application as a first time user.
In order to fix a problem, one must also understand the problem. This means knowing how to reproduce the scenario for which the selected item in the quick open produces the black bolded text. Being able to trigger the quick open panel also means having a method to trace the location of the source code file of interest. Due to the similarities between the debugger tool and Firefox’s native debugger (since this debugger is actually used in Firefox as well), I got confused thinking that I’m supposed to open my native Firefox debugger to open quick open.
Luckily, the Mozilla team had a slack channel. @anshulmalik, a team member of the repository, asked for steps to reproduce to figure out what steps I was missing to figure out the issue.
I realized that in order to get the command pallet to load as expected, I needed to be inside the debugger app browser window. When the app launched initially, it had a button called “Launch Firefox”. The browser window also looks different (it has an orange background for the address bar) so I thought that was the debugger. It turns out, that was the debugger’s browser to allow browsing of projects. The browser window which I pointed to localhost:8000 was the actual debugger. I needed to select projects on the debugger window in order begin debugging the project.
From there on, using Firefox’s native html inspector, I was able to pinpoint the html code associated with the command pallet.
There were two things that stuck out at me when I inspected the HTML element. A <div> with the classes selected and result-item which is associated with the highlighted item. Under that node is a title node followed by nested div node which contains a mark element. The mark element has a class named highlight. The mark HTML element contains the letter “t”, which happens to be the same letter I typed into the search box.
The next step was to find the name of the source file that controls this rendering. I went straight for the issue tracker and started searching for closed issues, looking for UI related issues and issues with regards to searching. During my search, I’ve found a particular issue related to the UI component I was working on. I dug deeper into the related pull request. The pull requests contains a files changed tab, which will give me clues as to the files that were modified by the contributor. A really interesting file stood out at first glance. It was named QuickOpenModal.js.This file was located inside src/components directory. When I located this directory inside the project folder, I saw QuickOpenModal.js. Bingo! Light bulbs went off in my head. At the same time, I realized that what I had been calling command pallet was actually called Quick Open.
After some experimentation, I was able to create the fix.
.selected .highlight {
color: white;
}
Once the updates have been pushed to the forked repository, I proceeded back to the repository and immediately I was greeted with the option to perform a pull request.
Clicking on the Compare & Pull request button presented me with a preformatted form to fill out which states the issue number, what I’ve fixed, and a test plan which entails a bullet-pointed list of how the maintainer can test to see if the fix was successful. In the request form, I’ve also included a screenshot to show the final result:
From there on, everything was history!
What I learned
I think the most important thing to mention is that opensource was not as scary as I had initially thought. I want to thank @jasonlaster for assigning me the bug and @anshulmalik for helping me through the issues I’ve encountered. I also want to thank professor Humphrey for encouraging me to choose a bug and introducing me to the Mozilla team.
It was a valuable experience learning the steps needed to contribute to any community; It begins with doing research about the project and understanding how the community works. This means reading the documentation made available and trying out the project. While there’s a tendency to think software developers work in isolated cubicles, working with opensource opened the doors to learning how to work with people across different cultures and geographic areas. Once the socializing settles, it is time to search for issues to tackle, then target the related source file and providing a fix.
I’ve also found GitHub pull request and issue templates to be interesting. Just by observing how other projects are managed allowed me to learn tremendously about opensource. Furthermore, knowing that GitHub has specific keywords that can be used as pull request titles, descriptions, and even commit messages to automatically close issues was an eye opener. This allows anyone to streamline managing issues, making the opensource experience even better.
Mozilla is also a major user of Eslint and Prettier. In fact, their Prettier configurations checks all files, even CSS files! That was shocking for me.
Issue titles are very important. What I thought was Command Pallet was actually Quick Open. Had I taken more notice of my issue title, I would realize that I could use that as the search word when searching through closed issues to find relevant closed issues sooner.
Steps to reproduce was, is, and will be a very important thing when tackling any bug. Being able to solve a problem means the individual needs to be able to encounter the problem first. This is true when listing an issue for others to resolve for one’s own projects or when describing a problem to a team member or mentor of a project you’re contributing to.
Finally, I’ve learned to ask for help. Having a great team such as Mozilla with mentors willing to extend their help gave me confidence to tackle tough bugs in the future. Asking for help means being able to pin point areas of interest faster. Furthermore, the folks with more experience can provide you with resources that you may not know enough about to google, which can help advance your knowledge when tackling a difficult problem.
opensource adventures 