Debugged: Debugging Empty String
Empty String. An infuriatingly vague error message that leaves few clues about what’s going wrong. A customer recently experienced a lot of these, and asked for our help debugging it. This is that story.
This error manifests itself as an empty string, "", passed into console.error. Browser errors can manifest in many ways, and many JavaScript libraries expose issues by writing error messages to the console rather than throwing them. TrackJS enriches these errors with a Stack Trace of where the message originated.
Stack Trace
The first frame of the Stack Trace is probably not relevant, as it points to the TrackJS agent itself. Because our agent wraps many of the browser’s functions, errors caught from those functions point to our wrapping as the most recent call. We’ve decided not to strip out that frame from our reporting to be transparent about the behavior.
Stack Trace with Inline Source
The second frame of the stack, on the other hand, looks relevant and appears to call console.error. We can see this in the inline code above, which is pulled from the sourcecode at s.pinimg.com. The code is minified, but TrackJS will prettify it and show you the relevant code automatically when the frame is expanded.
In this case, it looks like we have some code making a network XMLHttpRequest to ct.pinterest.com/user/. If the call fails, the xhr.statusText value is written out to the console. StatusText would normally say something like “Not Found” or “Server Error”, so why is it empty string?
Telemetry
The TrackJS agent records Network Telemetry, so we can see contexts about network requests made and active when the error occurred. Inspecting the Telemetry Timeline, we can see the request from the Stack Trace being made and that it has completed with status code 0.
Status Code 0 means the request failed because it was blocked by the browser or an extension. Browsers could block the request if they are directed to by a Content Security Policy (CSP). Such policies could be used to prevent potentially malicious scripts from stealing data. However, on this customer page there was no such policy.
Root Cause
Because the request was being made to pinterest.com, it seems likely that a Browser Extension, such as an Adblocker, prevented the request from being made. Adblockes are not uncommon, and frequently prevent requests to advertisers, social networks, and other analytics services from being made.
There is little you can do to prevent users from using adblockers on your website. Instead, minimize your use of ad, social, and analytics services and only use them in non-blocking ways. Your core application should function perfectly well even if Pinterest is blocked.
I recommend commenting-out these sort of widgets during your testing process to make sure the rest of your site operates well. You should avoid taking a dependency on them directly.
Once you’ve double-checked that your site works great if Pinterest is blocked, you can safely Ignore this error. TrackJS gives you Ignore Rules to remove these errors as soon as they are captured. A rule ignoring scripts from pinimg.com will do the trick.
That’s how we debugged this one, I hope that helps. There are so many different kinds of errors on the web, but TrackJS gives you lots of tools and context to help understand them. If you haven’t already, let us help you debug your JavaScript app. Get started today.
Until next time, happy bug hunting.
