Chasing Errors in Unexpected Places

July 17, 2020 6 minute read

After a long break from personal projects, the situation around the virus inspired me to build something on the side again. I’ll spare you the details but I decided to build a new kind of job board that would let developers browse open positions based on the technologies they are interested in.

It’s a straight forward full-stack JavaScript application that uses React in the browser, Express on the server and Dynamo for storage. As much as I wanted to give Go, or Svelte a try I wanted to ship something fast. Learning a new technology on the go wasn’t compatible with that goal.

The First Tests

So I invested around 40-50 hours in an alpha version that had all the basic functionality in place. It wasn’t visually fascinating but it got the job done. I decided to Heroku for the Express app and Vercel for the React one.

Once the alpha version was ready, I entered a few commands in the terminal and I it deployed for the world to see. I sent it to a couple of my friends to get some feedback. They told me what they liked and what they didn’t and uncovered a few bugs along the way. I had plenty of work to do.

“Probably nothing serious…”

One of the bugs they discovered was quite unfortunate. The most important feature of the app was a rich, long form which had a lot of client side functionality. It has different fields, WYSIWYG editors, file uploads, drag and drop elements and what not. Turns out the whole form didn’t on Chrome.

The app was still in its infancy so I didn’t pay much attention to that. I had probably broken something small by accident just before deploying. I didn’t even open the console because I expected to see cannot read property state of undefined or something in those lines. You know what I mean.

Probably nothing serious. So did I think…

The Plot Thickens

A couple of weeks later I had made some improvements and fixes. I settled on a name, picked fonts and colors and gave the app a bit of personality. It was time to ship the next version. I tested locally and everything worked fine, including the form.

I run a few commands, type the domain name in the browser and there it is. Everything looks great. I send out the links again and wait for the responses, tapping my foot on the floor. The three dots signaling that someone is writing appeared in the chat box. A couple of seconds later the first message popped up - “The form doesn’t work again”.

That’s not right I tested multiple times. I checked the console and there weren’t even warnings. I didn’t want this to be a blocker for the test so I rolled my sleeves up and started digging. I opened the form on the production environment. Wrote a few letters in one of the text fields - and the form didn’t work.

There’s a small preview widget on the side that should be updated as you type but it wasn’t working. No errors in the console either. I run the app locally and everything works seamlessly. There’s something wrong with the production environment.

But how could that impact the page? I didn’t use any environment variables there, nothing platform specific either. I decided to check the behavior in different browsers. Started Firefox, went to the app and opened the form. It worked. Everything was updated as expected. I started Safari and checked the form there. Everything works again.

We Knot Who, But We Don’t Know Why

My friend experienced the same behavior - the bug was only in Chrome. I was completely puzzled. I never thought that Chrome of all browsers would be causing unexpected bugs. It’s usually the others that require special attention. At least I know where the problem is - time to dig.

I rolled my sleeves up and opened the dev tools. I wasn’t using any unsupported browser APIs so it’s not that. No application errors but in the Network tab I see that some of the requests are marked as blocked without a status code for the response. Huh?

Unsurprisingly, those requests are for the JavaScript bundles that make the form page functional. The other pages are working fine, though. Their JS gets downloaded successfully. The one for the form, however, is marked as blocked without any message or any response.

My first thought was that a security rule in Chrome could be blocking the files for some reason. I did some reading around cookies, CORS, checked the configuration in Vercel but found no leads there. I scoured the web (and by that I mean Stack Overflow), searched for different phrases and problems that could give me some insight into what is happening.

No thread, or documentation page held any answers for me.

On The Verge Of Desperation

What I thought would be a trivial problem related to a missing check in JavaScript turned out to be a massive blocker. I can’t ship the app without the form. If it was failing only in Safari I could live with it. But this is Chrome - everybody’s using it.

At this point I had already spend my Saturday afternoon with no success. The wise thing here would be to call it a day and go back tomorrow with a clean mind. But since I was so invested I pressed on and continued to jam random words related to the problem in the search bar.

Then something happened. Somehow I put the correct combination of words, the stars aligned and at the top of the list I saw a link. It still had the blue color of a page that I still hadn’t opened. It was a question on Stack Overflow, of course.

I had already opened around 10 such threads, all with similar names, but hope dies last. I click on the link, hold my breath and start digging through the comments. Most of the responses and ideas I had already tried, they were of no help. But as I was about to click the back button, my eye was caught by one of the responses lower on the list.

A New Hope

It had the meager 7 upvotes but it was worth the try. All it said was to check the Chrome extensions since one of them could be interfering with the network call. Up until this moment I hadn’t even thought about them. They have access to everything on the page but in my 6 years of web development I hadn’t experienced any problems because of an extension.

But at this point I couldn’t rule it out.

I once again examined the unfortunate bundle. They are all named with an identifier, followed by a hash and the file extension - index, create, listing, advert. The blocked one that was breaking the form page was the advert bundle. I looked at the name for a second. Then I looked at the line of extensions next to the address bar. I looked at the name again. Then back to the extensions. Oh no…

A small red icon on the extension bar caught my attention - the AdBlocker. Could this be it? I disabled the AdBlocker and lo and behold - the page was fully functional. My friend got the same result. Apparently because the file contained the word advert it was getting blocked by the extension.

Everyone that tested on Chrome experienced the problem with the form. That’s because that’s their default browser and they most likely have some ad blocking add-on. Once they switched to another browser which they didn’t use and had no extensions installed, everything would work.

I didn’t expect AdBlocker to be that unforgiving but as a person who is not that fond of ads, I should be careful what domain language I use in my applications.

Live To Tell The Tale

So, this is it. The result of a Saturday afternoon spent debugging obscure problems. After such a session you usually go out of the room with a stern look on your face. Walking like a veteran with all your knowledge and the things you’ve seen. Well, I can’t say I learned anything new but I’ll be really careful with how I name my files from now on.

Tao of Node

Learn how to build better Node.js applications. A collection of best practices about architecture, tooling, performance and testing.