Our Funniest Front-End Bugs
When laughing is the only good answer
Bugs and weird malfunctions are a common sight for every developer. For frontend-ers, this is amplified by the frontend development environment, which is extremely diverse and quirky. It’s based on three different languages of three different categories (markup — HTML, style — CSS, and scripting — Javascript) which have their fair share of quirks; also, it encompasses different browsers, different devices, different capabilities (screen sizes, touch interactions, etc…), different OSes/platforms, the list goes on. Things are bound to get messy sometimes, which may lead to some cursing, but in the end, also brings some good laughs.
In hope of either brightening your mood or saving you a bunch of debugging hours in the future, here’s a list of the funniest, weirdest, or downright infuriating bugs we found in the (recent) past at THRON.
1. The most annoying
This bug surfaced when we were preparing a set of documentation pages for a library we developed and that our customers would use in their websites. We saw weird positioning issues with HTML elements while developing some but not all the examples. We couldn’t figure out why two simple HTML pages without custom CSS frameworks, libraries (besides our own), or anything fancy really, and with basically all the code shared between the two, had such weird inconsistencies. Then…someone casually mentioned DOCTYPE.
Turns out, roughly half of those pages had the standard <DOCTYPE html>specified, while the other didn’t (probably because of copy-paste mistakes). When browsers don’t find a suitable DOCTYPEdeclaration at the start of an HTML document, they fall back on the so-called “quirks mode” which is, well…quirky. It is a compatibility “feature” that allows browsers to not break when rendering non-standard web pages built back when the CSS specification wasn’t even finalized. It looks similar to regular HTML5… until it doesn’t. The subtle differences made this bug quite annoying to pinpoint. Once we realized the issue, adding back the DOCTYPEsolved the bug completely and “painlessly”.
…until you realize that you have to add back all those html, body { height: 100% } that for some reason were the default setting in quirks mode. How annoying…
2. The hardest to spot
While the previous issue was hard to spot, this one is on a different league. We have been reported errors that were caused by our customers trying to upload files to THRON. When trying to upload content with our “dashboard” web application, the client first uploads the file to a temporary S3 bucket, then calls a service that does the “heavy lifting”, fetching it from the bucket and importing it. The issue was caused by uploads done with Safari, and the files always had some kind of accented letter in the file name. However, we knew accents were handled correctly by our services, and couldn’t figure out why Safari would be involved.
After quite a bit of time wasted trying to understand what was going on, we discovered that:
- the “culprits” were files that used accents in the form of “combining accents” which are visually indistinguishable from a regular accented letter (we discovered it by randomly noticing that two filenames that should have had the same length actually had length different by 1 character because of combining accent usage);
- these files were correctly handled when using Chrome, but were causing errors on Safari;
- the filename is handled in two different ways when uploading to S3 and when calling our webservices: in the first case, it is passed as path parameter, while in the second it is passed in a POST having a JSON body;
- Safari applies a normalization to all request bodies that “collapses” combining accents to their single-character equivalent, but it doesn’t do the same with URLs; this difference was causing a name mismatch and a “not found” type error;
- the issue was not reproducible on Chrome since it doesn’t normalize anything.
The fix for this issue wasn’t painless; we were forced to normalize all file names as Safari does to avoid inconsistencies, and doing so we couldn’t guarantee the match between customer filenames and filenames in THRON, a property that was deemed desirable but needed to be relaxed because of this bug.
It should not be a surprise that Safari has gained the not-so-nice “new Internet Explorer” nickname among our frontend developers.
3. The recurring nightmare
A common UX pattern we use quite a bit in our web application is the “wall” visualization, which is a grid of blocks that resize themselves to adapt to the page width so that smaller devices see smaller thumbnails and larger screens fully use the available space. The responsive nature of blocks that allows such a good user experience, however, can cause issues:
You may have already guessed what’s happening: when resizing to very specific viewport sizes, the following loop is triggered:
- the user resizes its browser, increasing the viewport width;
- blocks expand horizontally and also vertically (maintaining aspect ratio), enough to require a scrollbar to appear;
- the scrollbar “steals space” to the content, reducing the width and prompting a reduction in block size;
- since blocks shrunk vertically, the scrollbar is no more needed and is removed, increasing usable width;
- go back to 2.
There are plenty of solutions for such a situation (style the content so that it doesn’t change width when scrollbars appear, or just make scrollbars always visible if that’s an option) however, none of those is really satisfying because they all prevent us from achieving the layout our designers envisioned for that interface. This issue leaves us the looming feeling that it’s not really “solved” completely, and it’s just preparing to pounce on us every time we develop something new.
4. The funniest one
This one isn’t a bug, just a funny interaction that made our day (and, unexpectedly, didn’t break anything!). After a deployment in our internal dev environment, we discovered that the application version we just deployed was “Infinity” for some weird reason. Since lots of us are fans of the Marvel universe, a meme was promptly created:
This funny incident was caused by our versioning conventions. We assign a version identifier to our internal/development builds with a pattern similar to X.Y.Z-<first-six-characters-of-commit-SHA>; this is then parsed by our build pipeline (Jenkins) which replaces it where needed in our application code. However, when handling a commit SHA starting with “6e1231”, a type-conversion mishap happened (it got interpreted as an exponential-notation number instead of a string) and our version skyrocketed to infinity. We have altered since then our versioning conventions, and we are happier with the new method, but I’m a little sad that the change prevented this bug from happening again.
5. The most unexpected
While developing our 360 Product View we stumbled upon an IE “bug” (no bug list could be complete without an IE bug) that caused us to basically waste an entire day trying to understand what was going on. We were trying to make our 360 implementation work with a jquery plugin that makes zooming painless on images. The plugin “captures” almost all mouse events and handles them internally, so we needed to intercept them before they reached the divcontrolled by it. Our solution was an overlaying transparent element that handled the events we needed to use and then forwarded the events to the plugin. With all those moving parts together, it was not surprising to discover that on IE9–10 we had issues intercepting events; however, when someone jokingly suggested replacing the divwith a transparent image, we were surprised to see the bug disappear. Apparently old IEs ignore mouse events on transparent elements, but a transparent image is enough to fool them into not ignoring events anymore. Besides the disappointment of being forced to employ such an ugly workaround, we still laugh at the “randomness” of the solution, since we end up employing a joke to fix an obscure bug we couldn’t figure out how to deal with otherwise.
Conclusion: humor is the developer’s best ally
Coding is a mentally taxing activity; it’s easy to let stress and (sometimes) anger take over and make the workplace a worse environment for everyone. That’s why I believe that memes and jokes are not a waste of time and being able to laugh at bugs or even at your own mistakes is vital. Finding time to enjoy the funny aspect of our job can only improve our and our colleagues’ work-day.
What are the funniest, most interesting, or downright weird bugs you encountered? Let us know in the comments!
