Skip to content

Instantly share code, notes, and snippets.

@Kriyszig

Kriyszig/eventloop.md

Last active January 23, 2024 15:58
Show Gist options
  • Star 1 You must be signed in to star a gist
  • Fork 3 You must be signed in to fork a gist
  • Save Kriyszig/bd10759269d0195b78b156d5bb223701 to your computer and use it in GitHub Desktop.
Save Kriyszig/bd10759269d0195b78b156d5bb223701 to your computer and use it in GitHub Desktop.
Download ZIP
Google Summer of Code 2020 [Mozilla - Inline CSS Compatibility Warning] Work Product
Raw
eventloop.md

Google Summer of Code 2020 Work Product

Organization: Mozilla
Project: Inline browser compatibility warnings for CSS properties in DevTools
Mentors:

Pre Google Summer of Code Journey

Start of the journey with Mozilla

Mozilla is one of the large organizations whose products touch millions of lives everyday. I was keen to contribute to their repositories even before I ever planned to apply for Google Summer of Code under them. My first set of contributions started with their project called Common Voice - an initiative to collect the largest open source labelled dataset for audio in the world. Most of my contributions were small UI related fixes for their website but it helped me understand a lot about the patch review process and using the Version Control System to my advantage.

Announcement of GSoC 2020 Organizations

I was thrilled to see Mozilla participating participating in Google Summer of Code 2020 and I quickly rushed to see what all projects they had in store.

I came from a Frontend Web Development background and was looking for projects in the same domain. That is when my eyes glanced over the project titled Inline browser compatibility warnings for CSS properties in DevTools in the project list.

This dealt with the one of the core product of the Firefox Web Browser - The Developer Tools - A product I use on a daily basis more than anything. Given it is something I have interacted with and have a visual working knowledge of, I decided to look more into it.

Setting up the Development Environment

The first thing I noticed was Firefox, unlike the repositories I had contributed to till that day, was on Phabricator and worked with Mercurial and not git.

So before buckling down, I had to get this beast of a Firefox repository cloned on my laptop. Now for some reason this is harder than it sounds. I ran into a lot of connection to server closed errors during the process and I couldn't understand why. This is when the community came to the rescue. I found there are Mercurial Bundles which are basically compressed file to the entire repository which can be downloaded first and then extracted to the local machine to get things working.

After setting up the development environment, getting a fresh build of Firefox up and running is just 3 commands away:

./mach bootstrap
./mach build
./mach run

In case of only JavaScript development, the kind I was about to embark on contributing to the developer tools, you can enable the Artifact Mode which will pull a pre built C++ binary instead of building it again on the local system. This takes the build time from couple of hours to half a minute.

Early Contributions

These were some of the Good First Issues on Bugzilla that I solved within DevTools to gain experience of the codebase and get to know the Mozilla engineers working on the DevTools.

Some of my initial contributions were:

There were a couple of patch that didn't get accepted as a result of problems persisting of MacOS (something I couldn't test visual behavior on) but I was extremely happy when the others were accepted and I could see them on the Nightly version.

Google Summer of Code 2020

I was one of the two fortunate students who got a chance to work on the project proposed for Developer Tools, the other being Manas who got to work on adding a visual debugging element to the Inspector to remove unwanted scrollbars by detecting overflowing elements - the project proposal

As were in an uncertain time at the beginning of 2020 and with my final exams still pending, I started my work on the project a little earlier than the original timeline.

Community Bonding Period and First Phase of GSoC

Community Bonding Period was the time I first met my mentors Micah and Daisuke over a Zoom call to get to know each other and discuss the project implementation in detail. One thing to note about my project is that the compatibility ecosystem is still in the early stages of development and a lot of changes were being planned on the fly.

This is where I was made aware that I will have to work on the Devtools' Server Side Architecture too in addition to the client side UI part.

Now you might be wondering what am I talking about Server Client pair in Firefox's Devtools. Well the gist is simple:

  • Firefox has a Remote Debugging Protocol that helps the Developer Tools talk to the underlying browser and get the necessary information.
  • Actors are server side element that are used to communicate with the platform and relay messages to the client (the Devtools UI side). Actors can also be used to run computation intensive processes to keep the main thread on the UI free and non blocking.
  • Actors respond to messages from the client and can even dispatch an event to the client for a change on the server side or on the platform.

My initial introduction to the RDP structure was from a former GSoC student's work product - Heng Yeow TAN(tanhengyeow) who worked on the WebSocket Monitor in Network Panel. His patches and his explanation helped me with my first set of patches for my project.

Coming to the patches:

A little side quest

Given compatibility panel was in its early stages of development, it didn't yet react to DOM Mutations. With the new Compatibility Actor, the compatibility check happened so much faster that the panel considered an outdated DOM (such as the loading screen on the Twitter) as the fully loaded one and only showed compatibility issues for it. This was bad news as for most client side rendered websites, the compatibility panel was empty in opened before page load.

To solve this rather than procrastinating, my mentors and I filed a few bugs to address this and then with their permission I got working on this side quest and finally created patches to process DOM mutations while rendering compatibility issues. This was done over the following 4 patches.

When it was all done, the compatibility panel reacted to DOM Mutations which enabled it to dynamically react to route changes on Single Page Applications

Second Phase of GSoC

Time to tackle the real beast - the tooltip component of the project.

Now Developer Tools already has several tooltip component but what we were using was th HTMLTooltip component used by the Inactive CSS Tooltip. The biggest advantage of working on a large project is that everything you need is already in some way already implemented for a general purpose use case.

This too was covered over a set of 4 patches:

Finally the patches were accepted after a thorough review and the initial implementation of my feature was finally in Firefox Nightly

Final Stage of GSoC

Sometime when working on large project, we tend to break stuff and I did too. I used the wrong key for a particular compatibility issue type that caused the tooltip to never render as a result of the error it produced serving undefined as the payload.

After informing my mentors I got to fixing the issue in the patch

There were some cleanups left in the actor side that as taken care of:

And last but not the least, Telemetry was recorded for the tooltip use:

Implementation details still under review

There are a few patches that are still under review. These are patches mostly related to moving the shared components to appropriate folders in the DevTools directory structure. These patches are:

Proudest Moment

The proudest moment for me was when the Mozilla DevTools Twitter Account tweeted about my work here and the community showed so much support for it. I'm happy someone somewhere is using my feature them time and allows them to be more confident of the CSS they ship.

Making the feature public

The feature will be tested in alpha on Firefox Nightly after which it will land in Firefox Developer Edition for beta testing and finally in stable Firefox release. This is done to ensure everything works correctly with the new feature and test for edge cases in real world scenario. Thanks to this process, the stable release and the developer edition remains stable whereas Nightly might break from time to time during experimentation (I kow this welll because I have broken it twice myself)

What went wrong?

Of course not everything went as expected - there were and are a lot of things that needs to be addressed. So far, all the mishaps are addressed with a blameless postmortem and fixes are deployed as quickly as possible with tests to avoid any future regression.

Already addressed

  • Broke and fixed the compatibility panel (Empty panel when opened before page load)
  • Broke and fixed the tooltip (Wrong key while accessing the JSON)

What still requires addressing

Future of the Compatibility Ecosystem

The future of Compatibility Ecosystem is bright. Some of the features planned are:

  • Displaying quick fix for deprecated properties / missing platform specific alias for particular properties
  • Show compatibility issues linked to HTML - For example the browsers that support native image lazy loading via the "lazy" attribute.
  • Eventually extend the compatibility check to JavaScript and Web API

Thank You

I would like to thank my mentors Micah Tigley and Daisuke Akatsuka. Without their mentorship, guidance and help, this would have never been possible. I would also like to thank the entire DevTools teams who were super helpful, friendly and patiently explained how the DevTools work. Thank you Mozilla Community for helping me start out with open source contributions to Firefox. Without the initial help, I wouldn't have been even able to clone the repository (^_^)

If you are a recruiter or are looking to recruit developers - I would like to bring to your notice the Mozilla Talents Directory - https://talentdirectory.mozilla.org. You'll find some of the smartest developers well versed in the emerging technologies and management on that page.

Last but not the least, thank you Google for hosting Google Summer of Code and enabling enthusiastic developers like us to help out with the development of these open source project that touch millions of lives every day.

Want to start contributing?

If you are a student or anyone in general looking to contribute to Firefox and DevTools, you can go to https://chat.mozilla.org/ to talk to some of the most friendliest people you can meet in open source community. If you want to talk to me personally about my work, feel free to reach out to me via Elements direct messages or by email - lelouch.cpp@gmail.com (my email filters are very forgiving so don't hesitate to write an informal mail).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment