The Hitchhiker's Guide to Servo Contributor - Part I

August 05, 2019

Motivation

Around 2 years ago, I decided to learn one more programming language. I found there’re two growing choices in the industry: one is Go and the other is Rust.

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.

Get Involved

Servo is a browser engine written in Rust. It’s famous for its parallel computation from its CSS engine and fast rendering by WenRender.

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 E-* labels. E means Effort here. For beginners, E-easy is basically equal to Good First Issue. After doing some easy tasks, E-less easy is good for next stage!

The process of my first PR

Implementation

My first PR to Servo was to fix an E-easy issue. I needed to update the accept_node which implements the algorithm of node filter in Servo to fit with the latest spec.

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 NodeIterator or TreeWalker object, same as @jdm’s note in issue description (the code is at components/script/dom/nodeiterator.rs and components/script/dom/treewalker.rs).

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 TreeWalker and NodeIterator.

After the implementation, how could I prove I wrote it correctly?

Web Platform Tests

Here comes the Web Platform Tests a.k.a WPT.

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 ./mach test-wpt.

In this case, two tests under /dom/traversal should PASS with the patches. They are /dom/traversal/TreeWalker.html and /dom/traversal/NodeIterator.html.

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 tests/wpt/metadata.

WPT Test Expectation

There are a bunch of ini files under tests/wpt/metadata.

They define the current status of the tests. If there’s no corresponding test status, then it means PASS.

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 PASS. In this case, I could just remove the ini file because no ini file means the whole test are OK and PASS-ed.

If no code change is required, a member will approve the PR and it will be merged after all CI passed.

Conclusion

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 E-easy or E-less easy
How Servo CI works
How to contribute to other projects outside of Servo

λ. Thoughts -> Text