ScrollTop and Other Bugs: The never-ending battle against bugs.
Did you ever hear the tragedy of Element.scrollTop? It’s not a story StackOverflow would tell you.
Through the magic of JavaScript, software engineers have the ability to tell if a user has scrolled all the way to the bottom of a particular screen or segment of a screen on a website. This can be particularly useful when we need to validate that a user has read through a legal document before agreeing.
To implement this, a generally accepted answer is to see if the element’s scrollHeight minus the scrollTop is equal to the element’s clientHeight
element.scrollHeight — element.scrollTop === element.clientHeight
This can be read as: when the difference in height between the scrollable document and how far we scrolled is equal to the viewable height we have reached the bottom.
We’re done, right? Not exactly. While testing out this solution we found a bug. scrollTop sometimes contains decimal values. So let’s go ahead and account for that using <== instead of ===.
element.scrollHeight — element.scrollTop <== element.clientHeight
Bingo! Ready to release.
One More Bug…
The next day we found one more issue. Some users were unable to continue on in the web page no matter how far they scrolled. To further exacerbate the issue our CPO encountered the bug while presenting our site.
Turns out we didn’t account for varying levels of zoom on the screen. Our assumption that “bottom” would be less than or equal to the clientHeight was true about 95% of the time.
So one more fix, let’s get rid of the decimals on scrollTop altogether by using a ceiling function.
element.scrollHeight - Math.ceil(element.scrollTop) <== element.clientHeightThis time, we account for the remaining 5%, and everyone can carry on.
Bugs vs. Engineers the never-ending battle
As software engineers, our day to day lives cycle between feeling like a programming god and a programming noob.
One day you are a half person — half machine hybrid that understands exactly where each individual line of code needs to go to get the expected behavior and the best performance.
The next day you have five StackOverflow tabs open, three cups of coffee on your desk, and you still can’t figure out how users can’t hit the bottom of an element on the screen.
Even the biggest software companies screw up. Facebook, Apple, and even Google have introduced bugs and security vulnerabilities in just the past couple of months. And yet, we still find ourselves believing we are just as logical and pragmatic as the computer we type on.
At Beam, we have a ton of tenured engineers. Lieutenants from different technology backgrounds that have done their time in the front lines in the battle against the bugs. We also have some brand new engineers. Bright eyed, bushy tailed soldiers that are just starting their battle. But we all unite under one common mantra:
We make decisions as a team, and assume positive intent.
When we encounter a seemingly obvious bug we move forward with the fix and know that when we introduced it we were working with all the information we had available at that time.
We also make sure to add tests. We endeavor to make all new, spectacular, never-before-seen mistakes.
If you are the type of engineer that would like to battle against the bugs at Beam, check out our openings, and bring your best failure stories. We love to hear about those!
