Shmeeps.org

I ran across an interesting error a few days ago while working. We have an application where a user is able to enter in information about themselves in sections. One of the many sections allows a user to associate their account with various organizations, communities, etc, which is aptly named affiliations.

While developing this section, we didn’t notice any problems, as each module code for each section is based off of the same base code, which should imply that if one section doesn’t work, the others shouldn’t as well. However, when the application was first demonstrated to the clients, we came across the fact that the section wouldn’t load. Since we checked this again when we got back to our development environment, and saw that it was working, we wrote it off as a temporary fluke in the testing server, or maybe a file that had not been successfully pushed to the server.

However, when the application was sent out for the clients to test, we received multiple reports of the section not loading for some of the testers. Looking into the environment for each user, we saw a common trait of it not loading for those using Firefox or Chrome, which is odd, since we figured that if any browser was experiencing the error, it would be Internet Explorer, which we have to support. Even stranger is the fact that when we compiled down the application with RequireJS, we found that the error in question was un-reproducible.

If you’re like me, when you get into a situation like this, where you have absolutely no idea what is going on, you just start to try random things, so we tried everything we could think of. We went through each line of code in the file looking for any obscure syntax or reference errors, hoping that maybe RequireJS just couldn’t parse the file. We reduced the file that wasn’t loading down to an empty AMD module that return a blank object, but the file still didn’t load. Finally, we tried to load a duplicate of the file called asdf, instead of the original. Oddly enough, this last ditch effort worked.

It was about this time that a co-worker noticed that the section loaded in a fresh install of Google Canary, but not in his regular Chrome. Since the only really difference between the two was that the Canary had no extensions or add-ons, he set about trying to sync the two’s settings to see if that helped. After disabling all extensions and add-ons, he found that Chrome then successfully loaded the file. He set about enabling them one by one until the file stopped loading to see what was blocking the file. The culprit? AdBlock (A fantastic extension by the way, use it if you don’t already).

Turns out, naming a file affiliations was not the best name to give the file. Apparently, AdBlock will make assumptions on requests it thinks may be ads, or anything else that might be blocked. The file in question met a bunch of what we assume is probable criteria: it was a javascript file that could run any number of loading/displaying functions and it was called affiliations, which is dangerously close to affiliates, which would normally indicate some sort of website or company that the website itself benefits from, eg, an advertisement. Though the file itself was legit, AdBlock thought there was enough criteria to stop it from loading. Turns out what we thought was a very complex, in depth and edge case error was a incredibly simple oversight that no one thought to check.

I think there are two very important lessons in this anecdote. First, when you have an error that you have no idea what’s causing it, check to make sure that your extensions are not causing the issue. Second, you should always try to check your application with some common feature-changing extensions installed, to see what they do. If we had not discovered this error, we may not have been able to tell a client anything other than “we don’t know why it doesn’t work for you; it works for us and everyone else!”