The Hitchhiker's Guide to Servo Contributor - Part I
August 05, 2019
After studying The Rust Programming Book and watching the into_rust() screencasts, I found the language is so fun and different from what I’ve learned before. I decided to try learning the language by contributing. I remember @shinglyu had a talk about Servo in Modern Web 2016 in Taiwan.
As a Front-End engineer, I’d like to understand more about how Browser Engine works and I’d like to find a OSS project to contribute and learn more about the Rust language.
About how to get involved in Servo, you can try to check the Servo Starters. It will list all the
Good First Issues.
Or, there’re some
Effort here. For beginners,
E-easy is basically equal to
Good First Issue. After doing some
E-less easy is good for next stage!
So, the first step of fixing the issue is to read the spec because I’d like to make the algorithm up-to-date. Spec says the filter algorithm is within a
TreeWalker object, same as @jdm’s note in issue description (the code is at
After reading and understanding the algorithm, I can start to update those 2 functions in each files. Also, @jdm mentioned that changes about spec update needs to add an active flag to both
After the implementation, how could I prove I wrote it correctly?
Here comes the
Web Platform Tests a.k.a
WPT is the unit tests for browsers. I will have a post about tests (including WPT, test expectation and how Servo CI runs those tests in detail) in this series so I won’t put too much details here.
Basically, as @jdm mentioned in the issue, the tests is under
tests/wpt/web-platform-tests/dom/traversal and we can run it with
In this case, two tests under
PASS with the patches.
So, from the above comment, they’re passed with
trying to run CI.
As @jdm said, I needed to remove corresponding test expectation for them under
There are a bunch of
ini files under
They define the current status of the tests. If there’s no corresponding test status, then it means
For the example of the PR, the
Recursive filters need to throw test case was expected to
FAIL because the implementation wasn’t updated to compliant with latest spec.
So, after the PR, the test expectation could be changed to
In this case, I could just remove the
ini file because no ini file means the whole test are
If no code change is required, a member will approve the PR and it will be merged after all CI passed.
After that PR merged, I tried to contribute to an issue for moving CSS longhands outside of mako and more other issues.
I will talk about those parts in my future posts.
Also, there are some topics I will write in the future:
- How to find an issue to fix when there’s no
- How Servo CI works
- How to contribute to other projects outside of Servo