Contributing to Thimble by Mozilla

Journeying into Open Source

The goal for our 0.1 release, was to find and fix a bug(s) in a Mozilla product or tool. I had chosen Mozilla’s Thimble, an online code editor that is designed to help new coders create their web-based projects, as my first open source bug.

I will discuss the steps I took to identifying the root of the issue and how I was able to apply that process to creating an effective solution. As well as the challenges I faced diving into the open source world.

Just a quick re-cap, issue-1918 involved displaying an appropriate header to the user once their project was successfully published or updated. The publish dialog header displays “Publish your project” regardless of the project’s status. The proposed fix was to change the header for a live/updated project to read “Your project is online”.

Track my progress: Mozilla Thimble Issue-1918

Source of the Issue

Since this was my time trying to patch an open source issue with unfamiliar code, I needed a plan of attack. Instead of trying to make sense of every file and line of code, I figured the best place to start would be by locating the source of the issue and progress from there. The way I see it is, reverse engineer a problem instead of trying to recreate it. This will save you a great amount of time!

My best bet was to make use of the inspector from dev tools to try to find the HTML element which produces the “Publish your project” string.

This pointed me to views/editor/publish.html where I was a little thrown off by the lack of markup and content in the html file.

After a quick Google search I discovered that it was using a Mozilla template engine called Nunjucks. Having never worked with Nunjucks, I looked through the documentation in order to gain a better understandings of its functionality.

Between the h1 tags is a function {{ gettext(“publishHeader”) }} which retrieves a localized string for a given key.

I was onto something!

The purpose of the templating engine is to generate the “clean markup” into standardized HTML for the browser to process. Nunjucks is able to retrieve and display the value of publishHeader,  “Publish your project”. BUT that string is not statically declared in the html file.

publishHeader is the key which stores the value of the string somewhere in the project.

In order to find a reference to the publishHeader key, I made use of VSCode’s search functionality. An extremely useful feature that will find every instance of a string within all sub directories. The result returned two instances of publishHeaderThe only instance was declared in locales/en-US/server-client-shared.properties. This file contains a bunch of static string definitions with not much explanation as to how they’re used.

Following a quick search through the thimble wiki I came across the Localization page.

“Every time a new string is added to the .properties files in locales/en_US and is committed, it will show up as an “unlocalized string” on Pontoon for each locale. There, contributors will localize the string and once accepted, it will show up on the staging server at https://bramble.mofostaging.net”

In order to make Thimble accessible in a wide variety of languages, static strings such as “Sign In” are defined in the appropriate .properties. Not only does this save the programmer from manually translating every string, it also ensures that the text is properly translated as well as reducing redundant definitions.

My next step was to examine the other elements inside views/editor/publish.html to try and figure out how they were controlled by the server.

There are other elements with classes defined as “hide”. What this means is that the entire view is delivered to the client which must be controlled by the server.

Once the project is published, elements like the delete button and share link are displayed by simply removing the “hide” class.

After searching for references of the other elements such as publish-buttons, I found that they were used in public/editor/scripts/ui/publisher.js. A JavaScript file that controls the values of the html elements and which elements are displayed to the user.

What we know:

• the /locales directory contains statically defined string
• • accessible through JavaScript functions
  • generated in a variety of languages with Pontoon
• “Publish your project” is not altered in anyway
• the publish dialog contains hidden elements controlled by the server
• content can be dynamically delivered to html elements
• html file doesn’t have access to the JavaScript functions

Solution

In order to control the value of the h1 element by inserting the appropriate value depending on the status of the project.

The best way to describe this is to break down each change I made.
Let’s examine the following dif snippets from commit 2c45484 :

• Line 23: publishHeader was moved from server.properties to server-client.shared.properties since it would be used by both the server and client.
• Line 24: created to define the status of a published project

• Line 17 – 18:  store the value of publishHeader and publishHeaderOnline from server-client.shared.properties.
• Line 39: adds a publishHeader property to the Publisher() object and access the h1 element within the content class from /views/editor/publish.html
• Line 323: checks to see if the current object has passed the conditions to allow the unupublishing of a project
• Line 325:  if it can be unpublished this means that the project is online. In result it inserts the value of TEXT_PUBLISH_HEADER_ONLINE to to the h1 element in /views/editor/publish.html.
• Line 330:  if the project is selected to be unpublished, the h1 element is reset to TEXT_PUBLISH_HEADER.Result