Yesterday I found myself searching for a new digital camera for an event I’ll be attending late this year. I was really hoping to find (both for thematic and nostalgia reasons) was a modern digital camera with analog-style physical interactions, like having to wind the film before you can take a picture.

I’m absolutely romanticizing it. Still, I can’t help but see my high school shooting process as meditative. I don’t remember specific events, but I distinctly recall the sensation of being on a photo trip. If I close my eyes, I can still see the darkened corners of the vignetted image in the viewfinder. I feel the two halves of the split microprism in the viewfinder slide by each other as I twist the focusing ring until they line up without a seam. I sense the tiny vibrations that cascade through the body of the camera and into my hands as I crank the film advance lever. Each push, pull, and twist guiding this complex machine fluidly into the exact state I want. And, as I exhale and depress the shutter button, I anticipate the clatter of mirror and leaf shutter that are just a moment away.

In the continual push towards digitization, I feel the loss of physical interactions that ground us in the moment. That make us sit with a passing thought for another breath. And, in doing so, that friction creates space for discernment and the opportunity to further reflect, filter, or refine.

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.