Recently I was asked to look into a pair of issues that could be seen in a live environment but not in test. After a bit of further investigation we discovered it could be replicated but only using BrowserStack, and only in their Simulators, not physical devices. This was a bit of a problem as the BrowserStack simulators do not have Web Inspector / Developer Tools and the target environment is shared by many developers and isn’t really the place of excessive debug code.
The Approach
- View the problem page in the Simulator
- Use a Proxy to watch the traffic
- Append a remote debugger script to one of the script assets
- Debug the issue
There are several remote debuggers available that allow us to view the DOM on the simulators;
For the Proxy I’m using Charles.
The hurdles
There are two ways to access BrowserStack,
- BrowserStack Local browser extension
- BrowserStack Local binary
Only the local binary supports our proxy and, as far as I know, on a Mac only Safari supports the binary;
./BrowserStackLocal --proxy-host HOST --proxy-port PORT --force-local --force-proxy
If you view BrowserStack.com and don’t see it in the proxy check your settings. On a MacBook any “Automatic Proxy Configuration” will take precedence over the manual values in Safari. If you turn this off you can set the “external proxy settings” in Charles to access the wider Internet.
What was the actual problem?
What I discovered was that the limited connection speed and processing power of the simulator caused the AJAX requests to back up and, it appears, a limit on concurrent requests to be reached. These dropped calls were returning a status code of 0, so they weren’t picked up in the server logs. Combining some of the calls together mitigated against the issue and the development team we’re reminded to be mindful of network performance…