Crazy Things We Found Developing New Relic Browser

When we set out to develop the JavaScript error reporting and AJAX timing features for the New Relic Browser, we had no idea what inanities we would find in the implementation details of various browsers. Sure, we assumed that by supporting everything from Internet Explorer 6 to the latest Chrome browsers we would be opening ourselves up to annoying edge-cases and the need for interesting work-arounds. What we didn’t yet know was exactly where those issues would manifest themselves, and some of the other interesting things that came out of completely instrumenting a browser’s environment. Here’s a look at some of the craziest quirks we came across!

Ghostly AJAX Requests

Sam Goldstein, a member of the New Relic Browser team, runs Earthquake Track. You can see all of the AJAX requests made by browsers while visiting his site in this section of the New Relic Browser AJAX dashboard:

Ghostly Ajax Requests

When Sam saw these requests he was very perplexed, because his app doesn’t make any AJAX requests. Where are these requests coming from? If you search for some of the listed domains, you’ll find that many of them are, or are suspected of, being malware-related. Our best guess is that these AJAX requests are made by malware extensions in the visiting users’ browsers.

You may notice as well that the throughput in requests per minute (rpm) is very small — much smaller than the number of pages served per minute for the site. This tells us that it affects a small percentage of the site’s end users, which also fits our malware browser extension theory.

To be clear, our suspicion of browser extension malware AJAX requests does not mean that the site is hosting malware; instead, this only means that some browsers that visited the site had malware installed.

AJAX request to http://localhost:0

AJAX requests work over TCP at the networking level: TCP sends data to IP addresses and then to specific ports. For example, HTTP traffic usually goes to port 80, and HTTPS traffic usually goes to port 443. While developing the AJAX requests feature, we found some requests were sent to localhost port 0. That’s a rather odd place to send a request to, because not only is the browser sending a request to the computer it is running on, it is sending it to port 0, which is a reserved TCP port. However, at the time we didn’t have a way to figure out what was causing the traffic.

During our closed beta period, a customer reported that when some users visited their site using Chrome for iPhone or Chrome for iPad, they were getting the following screen:

AJAX request to http://localhost:0 v 2

We were able to reproduce the issue by clearing all cached data and visiting a page instrumented with New Relic Browser as though we were visiting for the first time. From there we were able to narrow down to the root cause: Chrome was making AJAX requests to http://localhost:0/chromecheckurl, and this request was failing somehow. It also means we found the source of those AJAX requests to localhost port 0!

It turns out that as part of a workaround for having to build Chrome for iOS on top of the built-in iOS WebKit engine, the browser needs to use some tricks, such as using AJAX to hit a local HTTP endpoint, to do things like URL verification. Our instrumentation was somehow triggering a bug that caused Chrome for iOS to believe that valid URLs were bad. For now, we have disabled AJAX timing for Chrome for iOS, but we plan to bring it back soon with workarounds for this issue.

‘a.highchartsObject’ é nulo ou não é um objeto

'a.highchartsObject' é nulo ou não é um objeto

Quick: Which is the most common native language spoken around the world? If you said English, you may need to get out more! Both Mandarin and Spanish are more common native languages than our own. As such, it’s no surprise that we often see JavaScript errors in other languages. For example, the title of this section when translated to English is, “‘a.highchartsObject’ is null or not an object.” Fortunately, we make it easier to understand these non-English messages by providing multiple instances of the same error — the instances often have different languages for the error messages. When you’re stuck, Google translate also works well!

To infinity, and beyond!

These are just a few of the interesting things we have found through the development of New Relic Browser. Inserting ourselves into the inner-workings of the browser environment has yielded many unintended insights, and we expect to find even more with the features we plan to add soon. Stay tuned!

chase@newrelic.com'

View posts by .

Interested in writing for New Relic Blog? Send us a pitch!