How to avoid breaking the tree!

My journey as an Outreachy intern for Mozilla began about three months ago, and it seems like the shortest Summer of my life. This is primarily because the internship was fruitful on all levels. I got to learn so much, and the fact that my project is soon going to be live, makes me feel like I’m living the dream! I would strongly recommend everyone, who wishes to get momentous growth and new experiences, to apply for the Outreachy Program, and especially, for Mozilla!

With most of the project design and copy done, we are just left with writing some tests for what we have changed or added. I am getting to learn a lot about the test-writing process at Mozilla, because there are various ways through which one can test the tests.


Mochitests (just one of the automated regression testing frameworks used by Mozilla) have become my off-late best friend in test writing. Mochitest is an automated testing framework that is built on top of the MochiKit JavaScript libraries.These tests report success or failure to the test harness using JavaScript function calls.

Mochitest runs as part of the build and test process in Mozilla, so if something breaks, we get to know pretty quickly of the commit responsible for it. However, I still run Mochitest myself before I commit so as not to be the one who breaks the tree and hinders everything.

Build Mozilla with the changes

Run ‘./mach mochitest’


Run ‘./mach mochitest <path_to_specific_file>

Try Server:

The other type of rather generic method is to test a patch without actually checking the patch into the core repository by using Try Server. In order to be able to use Try Server, level 1 commit access is needed.

Firstly, some configuration will be needed by running: ./mach mercurial-setup. Then, there are several ways to schedule using Tree Herder. One could push to try by: ./mach try empty and then manually decide the jobs, or schedule jobs using try syntax by using mach. I personally go with this command:

./mach try -b od -p macosx64,win32,win64,linux64 -u mochitests -t none

Try chooser extensions and using mq are other techniques.

There are other methods to enable tests in Mozilla, but these two are the ones that I find the most handy! Hopefully as time goes by, I’ll be able to come across newer testing methods in order to make sure to not break the tree, and of course, make the web safer for everyone!



Enroute: Building Amazing Software

My Application Journey:

I had the aspiration of contributing to FOSS through Outreachy and working with Mozilla since over a year. Having subscribed to the mailing list for Outreachy’s Application information, when I saw the applications had begun, I rushed my way to the website.

I had spoken to previous Outreachy interns and they had one salient advice to give: “choose the project that you think you’ll love working on!” I remember spending a week going through all the projects listed by Mozilla, in detail, trying to ensure the one I picked complements my skill set!

“The goal is to build amazing software!” This is the first thing that caught my eye on the “Project Description” page for my project- “Improve the Firefox Certificate Error Pages”.

Instantly, I emailed my project mentor, Johann Hofmann, and got a very supportive response. The entire process of contributing to this project was so enriching that I remember thinking that even if I didn’t get selected, I’ll be left with indelible knowledge. That’s the best part about Mozilla: the community is very helpful. I kept contributing to the project even after the deadline because I had become extremely passionate about it. Eventually, the results came out and I was elated to know I had gotten in!

What is my project about?

The Firefox Certificate Error Pages are essentially the error pages that are shown to users when Firefox fails connect to a website due to a bad SSL certificate. The project aims at improving the copy and UX design of certificate error pages to be more helpful to both advanced users and regular users. We also intend to better detect and alert the user about issues with their computer, such as interfering anti-virus solutions or wrong system clock.

Mozilla is as open source as it can get and Firefox is created by a global non-profit dedicated to putting individuals in control online! The Firefox team conducted surveys and testings to best determine user feelings in order to improve the UI. They made us reach to the following conclusions regarding some changes we need to make:

  • The Design changes essentially aim at making more Information salient; allowing users to see all of the information at once and iconize more serious warning messages
  • Reword the error message to put more emphasis on the site rather than the connection
  • Provide instructions on updating clock and eliminate the error due to wrong system clock
  • Include “I Understand the Risks” button so that the user is sure about the potential risk

Some of the planned copy designs are as below:


This error page helps the user know about a potential security threat because of which Firefox did not continue to [name of website] ( If you visit this site, attackers could try to steal information like your passwords, emails, or credit cards.


To better understand the difference, you could compare it with the current certificate error page:
Screen Shot 2018-05-28 at 2.57.57 PM

Another important error page category we’d be tackling would be the Wrong System Error Clocks and this is the planned design:


This error page informs the user that their computer clock is set to [Month day, year, time]. They also see the message to ensure their computer is set to the correct date, time, and time zone in their system settings, and then refresh

These are just two examples of the copy that has been proposed. We have decided to pref-off and fork the error page code and have filed some bugs. We hope these would add small improvements, that will add up to a more pleasant overall user experience, along with improving the security and privacy of all Firefox users.

The Outreachy internship period has commenced, and I am super excited to finally be a part of what the project description said: “building amazing software!”


FOSS and Outreachy Explained in Laymen Terms


What is FOSS and why’s it so important?

Free and Open-Source Software is software that can be classified as both free software and open-source software. In simpler words, consider a software that you built, and out of generosity maybe, you made it available for everyone to use it for free. Also, people now could modify what you have originally created to suit their own needs. So now, it is both free and open software, in short FOSS.

FOSS is extremely important because of the following reasons:

As Mozilla’s one of ten commandments state, “Transparent community-based processes promote participation, accountability, and trust”.

Knowing the software on what you are working gives you the control over the system. If something goes wrong or you want any specific feature to be added, you can easily customise the open source software and push it for approval.

With so many brains working on a software, the bugs are fixed quicker and faster come the upgrades.

You can learn by watching the source code of the software and in future create an even better one.

What is Outreachy?

Outreachy is a paid, remote internship program for the underrepresented groups. It aims to getting them more involved with open source. Interns are paid a stipend of $5,500 and have a $500 travel stipend available to them.

Organizations like Mozilla, Wikimedia, Gnome, and Linux Kernel take part in the program. They hire interns to work on their projects. The duration of the program is three months.

Why choose Outreachy?

It is unique in a way that every intern works on a project for an organization under the supervision of a mentor. This is great because you get to learn a lot through the entire process, and if you get stuck anywhere, your mentor is always happy to answer!

Furthermore, it is extremely contribution centric, and takes you in if you seem fit for the internship task specifics.

When should one start applying?

The number of contributions you make obviously adds up to your application, so it is advised to start early (around 2-3 weeks before the deadline) so as to ensure quality and not just quantity of contributions.

It is also better for you to get familiar with the code base and make sure the project’s skill set matches with yours.

I would say the entire application process in itself is super enriching because you get to learn a lot with every bug you fix. Honestly, I developed a huge passion for the current project I’m working on – “Improve Firefox Certificate Error Pages” – by starting early!

I cannot wait for my internship to start:

It’s been just two days since the Outreach results were out, and I honestly cannot wait for it to start. I already feel so passionate about my project because I continued to contribute to it despite the application deadline being over.

Last, but not the least, a huge shout out to my mentor- Johann Hofmann, for his constant help in every tiny query I had, and the Outreachy organisers for coming up with the coolest internship ever! 🙂