Code Contributions to WebKit (release 0.3 for DPS911)
Preparation for Contributions
In order for me to finally be able to write and contribute code to the WebKit project, I had to go a very long way setting up all the modules and getting all the codes compiled. I experienced a lot of errors with different scripts such as check-webkit-style, run-webkit-tests, and build-webkit, and IRC community helped me a lot figuring out where problems can be.
As well, WebKit community gave me a good advice — using mini-browser instead of the whole production version of the WebKit, so I got the code running using run-minibrowser script and was able to test my codes faster.
And when WebKit finally began to work on my machine and I tested all the scripts I started looking for bugs on the official Bugzilla page of the WebKit.
Looking for the Bugs
In order to find the first bug, I spent a lot of time, but thanks to my teacher -David Humphrey, who helped me to find many different bugs that can be a good starting point, I was able to find a good first bug from that heap that I can fix.
Fixing Bug with Moving Codes Between Files
This bug is, in fact, a very small change to the code of the WebKit. In this bug, the community suggested just transferring the lines of code from one file to another. I saw that the status of the project was labeled as a “NEW” and I decided to immediately write the code and create the patch for the bug.
For fixing that bug, I just cut around 400 lines of code in one file (implementation file of accessibility/mac/WebAccessibilityObjectWrapperMac) and pasted them into another file (header file of accessibility/mac/WebAccessibilityObjectWrapperMac). After editing and building code, I tested it using the main test script(run-webkit-tests) and style checker script(check-webkit-style), fixed the errors that the style verification script generated and realized that I was ready to send the code for verification — creating a patch.
Creating First Patches to the WebKit
In order to create my first patch for the WebKit, I used the built-in script (webkit-patch upload). It led me through all the necessary stages of the process, including all the tests and writing a ChangeLog file. And finally, I submitted my change for the review. In a couple of seconds, my patch automatically appeared on Bugzilla and internal algorithms began to test my contribution.
Unfortunately, my very first patch was rejected by the internal style testing system on Bugzilla, because I used tabulation instead of spaces in the ChangeLog file, I fixed it and created a new patch that passed all the necessary tests on Bugzilla.
After some time, I received comments about my patch and community said that this bug really should not be solved because of some specific reasons described on the screenshot below. After understanding it I suggested to close it and change the status of the bug to “CLOSED”.
Ay the end, I was not upset because, after several weeks of failures with different WebKit scripts and after multiple attempts fixing them (thanks to the help on the IRC chat), I finally understood how WebKit project works how to contribute and create patches. Now I was ready to search for more new bugs and work on them, but some big problems were waiting for me in future…
Status as of 11 pm, 18 April 2019 — waiting to get bug closed by WebKit maintainers or for more feedback about whether it needs to be fixed or not.