Retrospective: How I spent hours of debugging code for a one-word bug

Tech

April 23, 2019 3 min read

I have been working on a project to move search in mobile from the bottom of the mobile menu out into the header next to the hamburger icon, with a search icon that when tapped opens the search box on top of the logo. Today QA found an issue in our integration environment, where opening the search box in the header and then attempting to open the hamburger menu caused the hamburger icon to freeze halfway through its animation from the hamburger to an X, shifted the icon down, and caused the menu itself to not open. This issue appeared only in iOS devices in one part of the site (called a subsite) and not in the main site or the sibling sites. These three categories of site shared much of the same code, but also had differences throughout the JavaScript (legacy jQuery and new Vue components) and CSS.

Since it only appeared in iOS devices and not Android or the Chrome emulator through the dev tools, we only had the dev tools in BrowserStack to troubleshoot, and the dev tools for iOS devices perform poorly compared to the Chrome dev tools, and are buggy. This issue also appeared to be an animation issue, a timing issue, or at least something JavaScript related due to how it presented itself. As it turned out, the issue had been in the code since several changesets ago and had simply not been caught earlier. This meant that looking at recent changes proved to be no help at all.

After having no luck for an hour and a half, the rest of our little dev team jumped in to help me troubleshoot. They focused on testing different devices and scenarios and looking through the dev tools, while I focused on the codebase, and changing things in the dev environment. I tried commenting out large portions of the JavaScript to see if that would make the issue go away (even if creating other issues), but nothing seemed to affect it.

I then reverted the code back to a much earlier changeset that was checked in soon after the initial commit. The issue did not appear in this older changeset. I began modifying files incrementally, changeset by changeset, testing every modification until the issue re-appeared. Then I modified the files line by line until I found the line that triggered the issue.

It was a simple CSS one-liner: position: fixed; needed to be position: absolute; for the subsites only.

I still do not know why this caused the issue in iOS only, or why it presented the way it did. The change was initially made to fix some other positioning issue in the main site and in the sibling sites, and though the code for the other sites are so similar to the subsites that broke, this one line made all of the difference.

A career in this field is made up of many days like this -- where finding a bug is where the challenge lies, not the fix itself. The fix was simple but the real work was in finding it.

Share

Think others might enjoy this post? Share it!

Comments

I'd love to hear from you, let me know your thoughts!