Sometimes a new release of a nightly version of a browser creates what we call a regression. How do we find out what exactly broke the code?
What is a regression?
In simplified terms, there is a regression when a code used to work and is not working properly after a specific release. For websites, a webpage would stop having the right behavior after updating to a new version of the browser.
Something was working with commit π of the browser and it stopped working with commit π+1.
How do we try to catch regressions before production release?
All browsers have different versions. The production release is the one that most people are using. The one which is advertised for people to download on websites and stores. But there are also beta versions and nightly versions.
The nightly version is a fresh working build with the latest modifications of the day. It's not considered reliable for your main usage. Even if browser implementers try hard to keep them stable, they may break. They may even damage your browser profile. Use them only if you understand the consequences.
- Chrome Canary (Blink) - No nightly release notes?
- Firefox Nightly (Gecko) - Release Notes
- Safari Nightly (WebKit) - Release Notes only for Safari Tech Preview
How do we find out the exact commit which has broken the browser?
You are now using commit π+π version which is broken. You want to find out the π+1 version which has broken the code.
You start bisecting the code. Let's say this is happening in between version 10 and 20 of the code.
- Verify this is working with 10
- Check this is not working with 20.
- Split the group in two. Pick up 15. Does the bug reproduce? Yes. So the issue is in between 10 and 15 No. So the issue is in between 16 and 20
- Take the new range and repeat and rinse, until you get a unique version.
That can become time consuming. There are tools to help with this task.The tool will download the nightly builds being tested and help figure out which specific commit in the code has broken the code.
Bisection tools
- Chrome
- Firefox. Probably the easiest to use of the 3. Well documented and even a version with a GUI
- Safari
Your turn! When you find out a broken Web page next time (when previously, it was working), follow these steps:
- open a bug
- Run a regression tool
- give the precise commit where it might have happened.
This will speed up a lot the potential fix.
Comments
If you have more questions, things I may have missed, different take on them. Feel free to commentβ¦. Be mindful.
Otsukare!