I wanted to learn a bit more about WebKit, so I decided to take a crack at fixing an easy looking WebExtensions bug 297838. This post just serves to gather a couple of notes on the contribution process before they fall out of my head.

Process

This assumes that you’ve

1. Select bug
   1. Find the bug you want to work on bugs.webkit.org.
   2. If you have rights, assign the bug to yourself. If not, comment indicating interest in working on the issue.
2. Submit for review
   1. Run check-webkit-style to make sure updates follow the style guide. Be aware that reviewers may ask for additional formatting changes on the PR.
   2. Run git commit (without flags) to create a commit message using the project’s commit message template. Provide all of the requested info and complete the commit.
   3. Run git-webkit pr. This will push an update to your personal repo on GitHub, create a PR on the main repo, and update the WebKit Bugzilla issue with a PR link.
   4. Once the PR is created, webkit-early-warning-system will leave a comment with links to test suite results. Make sure everything passes as expected.
   5. Wait for PR feedback :)
3. Iterate on feedback
   1. While working, make iterative changes locally and save checkpoints in Git history via git commit --fixup.
   2. Run git rebase --autosquash when you’re ready to update the PR.
   3. Run git push -f to push changes to your personal fork (by default, this remote is named fork).

Links

• Contributing Code
• Code Style Guidelines
• Testing Contributions
• Building WebKit. See Using Xcode for Xcode setup.
• WebKit Slack, #web-extensions-dev room (to join)

Building

webkit-build --debug

Testing

The set of tests that are run will be slightly different depending on whether you’re working with release or test builds.

run-api-tests --debug WKWebExtension*

Thoughts

• What’s the difference between git-webkit pull-request and webkit-patch upload?
  • Use git-webkit pr. It seems the webkit-patch command is an older tool originally created to support a different workflow.
• Xcode is weird.
  • I’m used to thinking about a project as a directory in my filesystem. Xcode has its own model of a “project” that is related to but distinct from that idea.
  • To find the current file in the navigator view, right click inside the editor view and select Navigate > Reveal in Project Navigator (Cmd+Shift+J)
  • When I first set up my local dev environment, I decided to use XCode because I assumed it would be the preferred tool. While trying to figure out the difference between git-webkit and webkit-patch, though, I realized that not everything in the repo is represented in the project navigator view. More specifically, there is no project in the workspace that corresponds to the Tools directory in the project’s root. As a result, searching the entire workspace for the string “pull-request” turned up no results.

Keyboard shortcuts

Open questions

• Can you get Xcode’s build command to play well with the webkit-build --debug and run-api-tests --debug CLI commands? If not, I may have to switch editors.