Hacktober Summary

Hacktoberfest was a really fun introduction into contributing to open source projects. It was a great learning experience. I've always had an interest in contributing to open source software but was always a bit too nervous about getting started with a new project - it was intimidating to ask to work on an issue as someone completely new to the codebase. Hacktoberfest forces you to step out of your comfort zone and work on 5 issues in a month, right off the bat.

What I Learned Through Each Pull Request

My first pull request tackled a layout problem for the focus-iOS web browser by Mozilla. Working on this issue taught me to take my time reading through a codebase that I am unfamiliar with - I shouldn't rush into a new project expecting to fix the issue quickly if I don't know the inner workings of the application.
After completing my first pull request, I noticed a new issue that dealt very closely with my previous fix. Because of my previous knowledge with the code surrounding the issue, I was able to quickly make the fix and submit my second pull request. Going from not knowing anything about the codebase whatsoever from the start of my first pull request to knowing exactly how to apply a fix for my second pull request was a really satisfying fealing. Working on this project allowed me to quickly learn that there's no reason to be nervous about starting on a new project if you take your take learning relevant parts of the codebase.
The third issue I worked on was for the Brave iOS browser. I thought it would be a good idea to work on a similar project to the one that I previously worked on. This was the first pull request where I had my code reviewed. This was a great introduction to the community aspect of working on open source projects.
I came back to focus-iOS for my fourth issue to work on another layout issue - this time more difficult and more critical than the others. I wanted to challenge myself going forward. At first glance, I had no idea where to start but after talking with the community and digging through the code, the fix became clear. Working on this issue taught me that just because something may look challenging, it only looks that way because you haven't read through the code yet. Once you do, the factors that play into the fix should become apparent.
For my last issue, I decided to work on a feature, rather than just fixing a bug. The fix itself wasn't too complicated because I knew what to look for because of my previous contributions. The problem was that the fix was supposed to mimic the functionality with the Android version of the browser but because I didn't have an Android device, I had to rely on the help of the community to guide me on the right path for this fix.

What I Learned

Hacktoberfest was a great learning experience. Because of it, I am no longer anxious about joining new projects. I have already experienced what it takes to begin contributing to a new project and know what to do for the next time that I choose to send in my first pull request to a project. Hacktoberfest also taught me about the community aspect of open source - there are people of all levels of experience working on open source projects. If you get stuck on something, you can rely on others to help fix the issue.


Hacktoberfest introduced me to projects that I see myself contributing to on my free time. This was a great experience to be a part of and I am looking forward to joining again next year.

My Pull Requests

• https://github.com/mozilla-mobile/focus-ios/pull/1416
• https://github.com/mozilla-mobile/focus-ios/pull/1420
• https://github.com/brave/brave-ios/pull/351
• https://github.com/mozilla-mobile/focus-ios/pull/1499
• https://github.com/mozilla-mobile/focus-ios/pull/1507

Hacktober V

This is my fifth blog post in my Hacktober Series. Throughout these 5 blog posts I hope to explain my introductory work into contributing to Open Source Software.

What I Worked On

I continued to work on the focus iOS browser for my fifth contribution for Hacktoberfest. This time, I decided to tackle implementing a new feature rather than fixing a bug. Due to the iOS and Android versions being made seperately, their codebase differs. The issue I decided to work on would try to lessen the differences between the two. I chose to work on adding a quick add to autocomplete tab. This would allow a user to add a website to their autocomplete list without having to go through the settings.

The Feature

The great thing about working with open source software is that a lot of the code has already been written for you. I researched how the layout is done for the already existing button in the dropdown under the URL bar. I added another copy, tweaked some parts, and created the functions called by pressing the button. To create the function, I referenced another part of the project. There is already a method for saving new URLs to the custom autocomplete list so I just had to copy and modify the already existing code to work in this scenario. Contributing to a project this size allows me to make valuable contributions by referencing existing code, all while learning.

Closing Thoughts

Hacktoberfest was a really fun experience for me. I got to contribute to projects that interest me and I'm sure I'll continue to contribute to these projects in my free time. This was a great introduction to contributing to the world of FOSS - something that I see myself doing more of in the future.

My Pull Requests

• https://github.com/mozilla-mobile/focus-ios/pull/1416
• https://github.com/mozilla-mobile/focus-ios/pull/1420
• https://github.com/brave/brave-ios/pull/351
• https://github.com/mozilla-mobile/focus-ios/pull/1499
• https://github.com/mozilla-mobile/focus-ios/pull/1507

Hacktober IV

This is my fourth blog post in my Hacktober Series. Throughout these 5 blog posts I hope to explain my introductory work into contributing to Open Source Software.

What I Worked On

I went back to the focus iOS browser for my fourth pull request. This time around, I decided to tackle an issue where pressing on the settings button would break the layout for the web view. The reason I chose this bug in particular is because of the needs investigating label attached to the issue. I figured it'd be a great issue to try to fix in order to continue learning about the codebase. To fix this problem, I had to investigate the cause for the broken layout.

The Fix

The fix itself was easy. Just like in my second commit, this fix was a line long.

The real challenge behind this pull request was trying to figure out what was causing the problem. After some digging around, I found out that the code was setting urlBar.shouldPresent to false when opening the settings popup (see code above). This caused the urlBar object to never call any of its delegate methods to active. Since it never activates, its layout remained deactivated as well. The webview bases its bounds based on the bottom of the urlBar - since the urlBar's overwritten constraints were never turned back on by the delegate methods, the webview used the urlBar's default constraints to base its own bounds on. This is what created the layout issue.

After looking through older commits for the functionality, I found that the reason that urlBar.shouldPresent was originally set to false was to prevent the application from displaying the overlay when launching from an extension. After failing to be able to reproduce this, I decided to ask the community and received a reply pointing me to the right direction.

After checking the history on git, I realized that the settings view controller was not originally presented modally and that's why the urlBar was turned of when viewing the settings. Since the change, the bug that setting urlBar.shouldPresent to false was supposed to fix was no longer possible to reproduce - instead of a fix, it itself became the cause of a new bug - so it was safe to delete.

My Pull Requests

• https://github.com/mozilla-mobile/focus-ios/pull/1416
• https://github.com/mozilla-mobile/focus-ios/pull/1420
• https://github.com/brave/brave-ios/pull/351
• https://github.com/mozilla-mobile/focus-ios/pull/1499

Hacktober III

This is my third blog post in my Hacktober Series. Throughout these 5 blog posts I hope to explain my introductory work into contributing to Open Source Software.

What I Worked On

This time around I decided to try out another open source Swift project. After some digging around Github, I found the repository for the Brave iOS browser. This felt like the perfect second project to work on since my first two contributions for Hacktoberfest were for the focus iOS browser. This would allow me to transfer my knowledge between the two iOS browser projects.

After looking through some of the posted issues I ended up finding one that I wanted to work on. It was a layout issue where a popup would clip off the phone's screen if it was in landscape mode. Instead of rushing into the problem, I decided to take my time and read through the relevant codebase - as I learned to do after my first Hacktoberfest contribution - to figure out an approach on how to tackle this problem.

The Fix

I had to work out a simple algorithm to layout the subviews to change their sizes proportionally to shrink the container to fit in the bounds of the screen. Initially, the code would set the heights of the views based on the available width and font size.

To fix the issue, I had to figure out the amount that every element had to be resized by to allow for the entire popup to fit on a compact screen. To do this, I had to take the external heights of the popup into consideration, including the buttons and the padding between the views. The following is the formula used to determine the resize percentage to fit:

The code was then changed to take the resize percentage into consideration.

Code Review

This was my first commit during Hacktoberfest to recieve a code review. The comments were mostly about best practics to follow and code cleanup. For example, one of the comments was about potential recursion within my code. After reading the comment I began to work on a method to avoid having to use recursion and reduced the risk of a potential bug arrising in the future. Having my code reviewed with suggestions on how to alter it makes me feel like part of a community. It's more than just a collection of people pushing code to a project - it's a community that works together to create the best codebase possible. Being able to have a back-and-forth discussion with my reviewers makes me feel like an equal even though I'm new to the project.

My Pull Requests

• https://github.com/mozilla-mobile/focus-ios/pull/1416
• https://github.com/mozilla-mobile/focus-ios/pull/1420
• https://github.com/brave/brave-ios/pull/351

Hacktober II

This is my second blog post in my Hacktober Series. Throughout these 5 blog posts I hope to explain my introductory work into contributing to Open Source Software.

What I Worked On

After my first Pull Request to Mozilla's focus browser for iOS, I saw that a new issue was opened in the repo - one that was very similar to the bug that I just fixed.

I made a comment on the issue that I could work on it as it related very closely to my previous pull request and began to look through it. Unlike my previous work that took me a couple days to fix, this one took me less that 10 minutes. It was so closely linked to what I previously worked on that I immediately knew what the problem was and how to fix it.

The fix itself was less than a line long - all I had to do was change the object that was being affected by the functions. I changed the code from addGestureRecognizer(singleTap) to textAndLockContainer.addGestureRecognizer(singleTap).

When I first sent in the pull request, I undervalued the work a lot. I didn't think that a commit this small was anything to be proud of. But then I realized that this fix that took me less than 10 minutes to fix was only possible because of my past commit that took over 2 days to fix. If I tried to fix this bug without having fixed the previous bug, I'm sure it would have taken me much longer to figure out.

Through this fix, I've learned that what may seem and look like a simple fix to someone who has worked with the code before, may not be as simple to someone coming in for the first time. It was also a very good introduction to how previous fixes are great at paving the road for future fixes.

The more you work, the more you learn, the quicker and more simple fixes seem to be. The more you work on a project, the more familiar you become with how to continue improving it.

My Pull Requests

• https://github.com/mozilla-mobile/focus-ios/pull/1416
• https://github.com/mozilla-mobile/focus-ios/pull/1420

Hacktober I

This is my first blog post in my Hacktober Series. Throughout the next 5 blog posts, I hope to explain my introductory work into contributing to Open Source Software.

What I Worked On

For my first Hacktober Pull Request, I decided to contribute to Mozilla's focus browser for iOS. This is a browser written in the Swift programming language with the intent of an increased anonymized browsing experience. I looked through the issues and found one that I thought was simple enough to do within a week yet would provide a challenge. Fixing the bug wasn't as easy as I thought it would be - the solution wasn't too straightforward - but with the help of the existing code as reference, I was able to find a solution.

I Think I'm Too Used To School Work

When working on a project at school, the instructions are laid out for you. You know which functions to work on, what they should do, and what they shouldn't do. Working on OSS was a completely different experience. School work is straightforward and because of that I'd be able to jump straight in and code. Being used to coding in this way made my first day trying to fix the bug very frustrating. After a day of trying to fix functions that looked as if they could be related to the bug without success, I decided to look at it again the next day.
This time, I decided to take my time. I removed all of my edits to the code and spent around an hour just reading the code and drawing out the dependencies. This finally allowed me to find a solution. In the future, I plan on spending a majority of my time reading the code, as opposed to my previous strategy of code first, read later.

My Pull Requests

• https://github.com/mozilla-mobile/focus-ios/pull/1416