Tag Archives: geolocation

updating the geolocation tests

With Firefox 3.5 coming out the door in the near future, one of the many new features is geolocation (don’t worry you have full control over this, no loss of privacy required).

The existing automation is done as a mochitest suite. This includes a set of tests, a testGeolocationProvider (replacing the one build into firefox when building with –enable-tests) and any glue to make it all work. This works fine, but as we learned the test provider is not included in release builds and the tinderbox automation could not test for all builds.

The solution is to originally rewrite the whole set as browser-chrome, but we realized that we should just write a dummy network provider (instead of the default provider: google).

In figuring this out, it ended up being quite easy. There are only a few parts to this:

  1. Create a webpage that could receive and send json data in this format
  2. Find a method to host the page, ideally inside of the mochitest harness
  3. Add the glue to ensure it all works
  4. Cleanup the old code

The Json bit is easy. Looking at the NetworkProvider there is an example of what we expect back. Also Google has a great document outlining the Geolocation API. Put those two together and you have a simple bit of code to give you the same hardcoded functionality as before:

function handleRequest(request, response)

var coords = {
latitude: 37.41857,
longitude: -122.08769,

altitude: 42,
accuracy: 42,
altitudeAccuracy: 42,
heading: 42,
speed: 42,

var geoposition = {
location: coords,

response.setStatusLine("1.0", 200, "OK");
response.setHeader("Content-Type", "aplication/x-javascript", false);

Now to put this on a webserver, I found that in mochitest we use httpd.js as a localhost webserver and it supports GET/POST traffic. This is too easy when you just have to put a file in the test directory as a type .sjs and reference http://localhost:8888/filename.sjs.

Ok, onto the glue. This is even easier. Since we have a live webserver that returns proper data, we just need to make sure our geolocation requests get there. We have a preference (geo.wifi.uri) and this is done in automation.py which generates a fresh profile when we launch mochitest.

Lastly is the cleanup, and here I just removed all references to testGeolocationProvider.js as well as the file itself. I did find that we didn’t use the ensure_geolocationProvider() function in the geolocation_common.js anymore, so all references to that have been removed as well.

The only other useful information I had while working on this was how to debug. For the NetworkProvider (just uncomment line 12/13), I used the error console inside of Firefox (SHIFT+CTRL+J). This provided great details as to what was happening. Also in the httpd.js server there is a function dumpn which outputs to the command window that launched firefox (what you normally call the console). You either have to build in debug or comment out the “if (DEBUG)” condition.

Now I have working tests that resolve a lot of problems. On my plate and delayed (mostly because of waiting to figure out the outcome of this test provider bug) is a bug to add more comprehensive tests. These have been difficult to sort out since I had to execute code inside of setTimeout() to gain access to the right context. With this new json network server, I can add code to the server to update the returned values much easier than I was doing previously.

Leave a comment

Filed under testdev