You spend a whole month developing a new feature for your Web App. The deploy day has finally arrived. You merge your branch with the main one and boom. It’s in production. Task done. You did it. Congratulations.
But then, after 5 minutes, you test it on your phone and you catch a very awkward bug in production. As an iPhone user, your first thought is: “Ok, it must be Safari. I’ll test it on Google Chrome”. Then you figure out it’s actually happening on Google Chrome too.
Alright. Time to test it using another device. Let’s try an Android one. The damn bug is not happening here. Sh*t. The problem is only happening on a specific mobile device. What should I do now?
That was my scenario today and I’ll tell you what were my approaches to handle it.
Usually, when you have problems with your code, you reach out to the glorious logs (😍). But how it would be possible to have access to that specific mobile device’s browser logs?
I started googling things like “JavaScript bug only happening on mobile device” and I found out some browsers got an AMAZING feature called REMOTE DEBUG. This feature helped me a LOT and actually I had never heard about it. Here are the links explaining exactly how to do it on Safari and Chrome.
After successfully having access to the logs, you start to have a clue of what’s happening. Unfortunately, the down side of using tools like Babel and Webpack is that it makes it tough to debug production problems. In my case, the logs were saying something like: r.addEventListener is not a function
“r”? WTF… 😂
In my case, I’m working on a HUGE Web App, so it’s hard to find and solve these problems just by debugging the application, since there’s a lot (custom hooks, providers, events, dispatches) happening at the same time.
Sometime ago, Sibelius (one of the smartest people I know, you should definitely follow him) told me that a good approach to solve awkward bugs is by trying to isolate the problem and reproduce it on a smaller context.
So I started searching by “addEventListener” in our codebase and trying to find code smells around it. After finding possible problems, I decided to start by the one I’ve thought it was more probable to be the one I was looking for. I extracted the logic (it was a custom hook) and put it in an existent project (I have a POC on my github using the same stack we’re using in my job — definetely recommend you to do it) that I would be able to test it on that problematic device. After confirming it really was the problem, I’ve tried to fix it on that smaller concept.
And… Wohooh 🎉🥰✅! You did it (now for real)!!!
The final step was of course deploying the fix to production and save the old browser’s user life.
This is what I wanted to share with you today! It was a very rich experience and I’ve learned a lot. Thank you for your attention!
Disclaimer: in my current job we use tools to help monitoring our production environment and before doing all of these things, I checked if it was affecting a lot of users. After certifying it was affecting almost nobody, I did what I did. I would never let a bug in production for so long if it’s harming our users experience :)
If you’re curious about what was the problem: I had a custom hook called “useMedia” to tell me if it was a mobile device or a desktop one. In order to do it, you need to use a browser feature called MediaQueryList. The MediaQueryList interface provides some methods and they’re deprecated, so I thought it was fine to use the new ones. Well, it wasn’t. In that case, it was better to use the deprecated methods since they’re widely accepted by browsers.
Feel free to reach me out on Twitter!
Top comments (2)
Oh man that sort of pesky bug is really hard to track down and debug, glad u managed to resolve it!
Yeah! I hope I can help someone by sharing my approach