Organization: Mozilla
Project: Inline browser compatibility warnings for CSS properties in DevTools
Mentors:
- Micah Tigley - Phabricator, Github, Twitter
- Daisuke Akatsuka - Phabricator, Github, Twitter
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.
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.
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.
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:
- Bug 1592243 - Fix diacritics truncation in network blocking panel r=Honza,fvsch
- Bug 1590990 - Prevent blocked icon from being draggable in Network Monitor r=Harald,Honza
- Bug 1585313 - Fix display of multiple close button on click and drag in network blocking panel r=Honza,nchevobbe
- Bug 1625406 - Remove the invisible add button in network blocking panel's top enable bar r=Honza,davidwalsh
- Bug 1636385 - Disable context menu options if blocking is enabled/disabled for all URL in Network Blocking Panel r=bomsy
- Bug 1596091 - RFC: Adding drag and drop feature to block URL in netmonitor r=Honza,Harald,bomsy
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.
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 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:
-
First task was to move the MDN Compatibility library to a shared folder so that it can be access on both server side (for computation) and on the client side (for unit tests).
Bug 1635768 - Moved MDNCompatibility library to devtools/shared r=mtigley,daisuke -
Implementing an actor to handle compatibility issue computations and connect the existing architecture to use the Actor instead of the library directly on the client side.
Bug 1635768 - Moved MDNCompatibility library to devtools/shared r=mtigley,daisuke -
Add tests to ensure everything was working correctly within the newly added Compatibility Actor.
Bug 1637632 - Add browser tests for the CompatibilityActor r=mtigley,daisuke
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.
- React to inline style changes - Bug 1644428 - Enable Compatibility Panel to react to attribute Mutations r=daisuke,mtigley
- React to DOM Mutations (insertion and deletin of nodes) - Bug 1644428 - Enable Compatibility Panel to react to dynamic DOM node insertion and deletion r=daisuke,mtigley
- Bug 1644428 - Added tests to verify Compatiblity Panel reacting to DOM mutations r=daisuke,mtigley
- Bug 1644428 - Cleanup: Arrange actions, reducers, imports and function in alphabetical order r=daisuke,mtigley
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
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:
-
The first one made modification to the actor we implemented earlier on. Till now we were using the node to get the compatibility issues but for the Tooltip we already had access to the declarations. Hence we needed to expose the function to get compatibility issues based on the declarations.
Bug 1649018 - Expose compatibility computation for CSS declaration block via CompatiblityActor and add browser dataset fetch r=daisuke,mtigley -
Add prefs so that people don't accidentally use in development feature before its ready to be shipped.
Bug 1649020 - Add pref for inline CSS incompatibility warning in inspector ruleview r=mtigley,daisuke -
Implementing the tooltip itself was not complicated as I just followed the implementation path from the Inactive CSS Tooltip (perks of working on a large project with similar features). The main problem however arose when wanted to reuse the existing components from the compatibility panel and the tooltip was using
innerHtml = HTMLString
which took a while but my mentor Micah came to the rescue as she found a way to integrate the React component within the HTML Tooltip.
Bug 1649021 - Add tooltip in rules panel to highlight CSS compatiblity issues for particular declaration r=mtigley,daisuke -
Add the tests to ensure correctness
Bug 1649021 - Add tests for CSS Compatibility Tooltip r=mtigley,daisuke
Finally the patches were accepted after a thorough review and the initial implementation of my feature was finally in Firefox Nightly
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
- Bug 1658356 - Fix the incorrect object key for the Tooltip message ID r=daisuke,mtigley
Complete with the test, we can be sure this case will not reappear in the future.
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:
- Bug 1657984 - Part 1 - Add telemetry for CSS Compatibility Tooltip r=daisuke,mtigley
- Bug 1657984 - Part 2 - Test the telemetry for CSS Compatibility Tooltip r=daisuke,mtigley
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:
-
Move a set of constants from server side to shared folder to avoid importing server side code on client side.
Bug 1657537 - Part 1 - Move the ISSUE_TYPE property to shared constsnts file r=daisuke,mtigley -
Move the MDN Compatibility library server side now that we have moved the constants needed in the above patch.
Bug 1657537 - Part 2 - Move MDNCompatibility library and related files to devtools/server/actors/compatibility r=daisuke,mtigley -
Move the React components shared between the Compatibility Panel and the Tooltip to the shared folder.
Bug 1657537 - Part 3 - Move shared component between compatibility panel and compatibility tooltip to devtools/client/shared folder r=mtigley,daisuke -
Move the snapshot tests for these React components to the shared folder too.
Bug 1657537 - Part 4 - Move snapshot tests for shared components from inspector/compatibility to shared/compatibility r=ladybenko!,daisuke,mtigley -
Remove code replication on actor and server side by moving User Settings to shared folder.
Bug 1653520 - Remove code replication in the compatibility actor by moving UserSettings to shared folder r=daisuke,mtigley
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.
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)
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.
- Broke and fixed the compatibility panel (Empty panel when opened before page load)
- Broke and fixed the tooltip (Wrong key while accessing the JSON)
- Some tests fail on Windows build (hard to reproduce) - Bug 1657807
- Accessibility issues with the tooltip - Color Contrast Issue - Bug 1660081, Keyboard Navigation Issue - Bug 1660083
- Performance Regression caused by associating compatibility issues to the rule view's actor response even when the pref is disabled Bug 1660047 - The Patch D87613 indirectly addresses this perf regression.
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
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.
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 - [email protected] (my email filters are very forgiving so don't hesitate to write an informal mail).