Bisecting Chrome

In last year or so it happened that I had to bisect Chrome/Chromium versions multiple times to verify if the issue is actually a browser bug rather than a bug in our product’s code.

That’s why I wanted to write the process down with all relative resources, so I don’t have to look it up all the time.

What is bisecting?

Bisecting means dividing something into two parts. And is exactly what git bisect and binary search do.

1. Tools

Chromium has a python script for bisecting in the repository. We just need to download it – tools/ And it requires Python 3 to work.

More info and examples are in this guide: Bisect builds.

2. Finding a version range

For any bisecting we need to have a ref of one good and one bad revision. In most cases the bad one is going to be the current stable version that we or our customers use. We can look it up in chrome://version. For example: 83.0.4103.61. Unfortunately this is not what the tool expects, and we need to convert semver version number into a Branch Base Position. And we can do that by using another tool, called chromiumdash.

chromiumdash — Chromium data, all in one place.

IMPORTANT: Branch Base Position is not a build number.

3. Bisecting

Once we have a good and a bad branch base position we can go straight to bisecting:

$ python -a platform -g good-revision -b bad-revision --use-local-cache

After running this command will lunch a browser with a picked version. Quit the browser and this script will prompt you about the results of testing this particular browser build.

Once finished bisect script gives a link to a range of commits included in a broken build.

Unfortunately it’s impossible to go to a by commit level of granularity if you are not a Google employee…

All of the links mentioned above:

Discuss on Twitter Edit on GitHub