Monthly Archives: May 2009

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);
response.write(JSON.stringify(geoposition));
}

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

initial evaluation of device anywhere

One issue when developing software for mobile devices is the need to test it on all devices you support. For mobile devices each carrier contracts with a manufacturer and gets a unique OS for the hardware platform they choose. As you can imagine there is a very large hardware/os matrix even if you are just supporting a couple mobile OS’s (maemo, windows mobile 6+).

So one approach we are looking into is deviceanywhere.com. This is a company that provides an online service where you can access and get full control over a given mobile device. What is even better is these devices have access on all carriers are are geographically spaced out!

Today I did my initial eval of the service and really liked it. You have to download proprietary software which is easy to download and install (tested on Mac OS X 10.5.7). There is a web based account management tool where you can buy credits, see your usage, access screenshots, upload files for later use, etc… Overall it is a pretty usable package with lots of flexibility.

My first test was to pick a Palm Treo and install Fennec on it. You can filter devices based on carriers or other high level things (I filtered on windows mobile [us/ca]). Unfortunately you cannot filter on carrier, hardware specs (touch screen, RAM, cpu). This is really easy to use and the response time is fast. Launching IE, searching for Fennec A1, and finding the release notes was an easy process. Installing was sort of problematic as the release notes reference a http site and we need ftp when using pocket ie! Here is where I found that using the keyboard (arrow navigation, and typing) is a slow process.

Fair enough, In 20 minutes of air time I had figured it out, downloaded fennec and had it running. Not so bad, I just wouldn’t want to spent 15-20 minutes installing Fennec each time around. I get testy and acquire another device for testing. Very easy and it becomes obvious that I can do 6 devices at a time (3 on the screen, and 3 off the screen). Unfortunately I start running into more problems with the other devices. I couldn’t even get a web browser started for 10 minutes on a blackjack device (finally realized it wasn’t a touch screen), then when I did, why can’t I do a search! Same luck on a Verizon tablet (I assume it is an lg brand) although it is touch screen, I couldn’t figure out how to get to the internet.

Well, enough of that. I did see the potential and found some great tools. For example, on each device that you access, you can reboot, unplug, pull out the battery, connect a data cable or grab a screenshot:

Fennec on Palm Treo

Fennec on Palm Treo

.

As a summary here are the pros and cons:

pros:
– easy to use for check in/out of devices
– full access to device with tools to do just about anything (hardware keys and all)
– wide selection of devices and carriers and physical locations

cons:
– learning curve on each device
– lack of filtering in device selection even if you know what you want
– slow input for accessing the device (although this is the case in person)
– could get costly if you spent airtime minutes for learning curve or installing special software

I still have about 100 minutes left to evaluate, next I will try some basic website testing and look into some of the scripting capabilities they offer (record/playback, automation of UI).

Leave a comment

Filed under reviews

automating fennec bookmark manager

This is more of a technical note and probably a boring read for anybody not interested in test development for fennec.

In an effort to add real automation for Fennec we have had issues making progress using browser-chrome to develop tests. Our latest bits of work come from bookmarks where happyhans is adding additional tests to what zad started (let me note that zad really paved the way for these tests on Fennec).

One thing we were trying to figure out is how to click on the edit button while managing bookmarks. It would be nice if we could just reuse test code from Firefox, but that is not an option. So using DOM Inspector and a lot of other help on IRC, browsing source code and just hacking, I have found the method to click a bookmark.

    chromeWindow.BrowserUI.showBookmarks();
    chromeWindow.BookmarkList.toggleManage();

    var bookkmarkitems = chromeWindow.document.getElementById("bookmark-items");
    var bookmarkitem = window.document.getAnonymousElementByAttribute(bookmarkitems, "class", "bookmark-item");
    var editButton = window.document.getAnonymousElementByAttribute(bookmarkitem, "anonid", "edit-button");
    editButton.click();

A lot of this code :happyhans did. I found out the last two lines where we have a list of bookmarks and just need to find the “Edit” button to click.

What we see here is getting a list of bookmarkitems with getElementById limits our scope and returns a XULElement. Inside this Element, we have a list of “bookmark-item” classes which contain the bookmarks and the buttons to interact with them.

Since there is no ID on the bookmark-item, I query it with the getAnonymousElementByAttribute but here I start with my bookmark-items and look for a class named “bookmark-item”. This sound straightforward, but finding examples of other code to do this is not really possible.

Lastly, I took the bookmark-item (which defaults to the first item) and search for the “edit-button” as it has a “anonid”. I found out all of this information using the DOM Inspector (once mfinkle helped me use it properly).

So that is the basics. This code needs some real love to make it work with a specific title or URI instead of defaulting to the first item in the list. Knowing what I do now gives me some confidence in being able to figure out how to solve other problems in the bookmark manager.

Leave a comment

Filed under testdev

using dom inspector with fennec

Today I dove in headfirst on automating bookmarks from browser-chrome. I normally read the code to figure out what is going on, but instead installed DOM Inspector and my life became much easier.

I found a post on mfinkle’s blog and started there. This didn’t work so well (we have incremented Fennec version since it was last modified) so I installed it on firefox and then copied the extension to fennec. This can be done by looking in your extensions directory inside your profile ~/.mozilla/firefox//extensions/inspector@mozilla.org/* and then copying all of that to ~/.mozilla/fennec//extensions/inspector@mozilla.org/.

This is all assuming you have installed Fennec and it uses your default profile directory. In my case, I have many versions of Fennec, so I have to go into my Fennec/extensions directory and copy the inspector@mozilla.org to it.

Ok, once installed, I fired up fennec, and hit CTRL+SHIFT+I and up popped the inspector. Being a n00b, I didn’t figure out the file->”inspect chrome document” for about 5 minutes, then it started making sense and I was able to drill down and figure out the layout inside of Fennec.

3 Comments

Filed under testdev

a useful tool – waze

I saw this on digg and thought back to my days at microsoft where I proposed making a similar product (using public transit actual travel times vs published times to predict the traffic levels) and was given a “oh that is nice” reply. This company seems to have made this work using cell phones as the source and gps:

http://www.waze.com/

There are a lot of great uses for this data and over time building a predictive model for traffic that is reliable becomes a reality.

I hope this is successful, and if it isn’t maybe I need to start writing code

Leave a comment

Filed under Uncategorized

Debugging and python don’t mix

Earlier this week I spent some time getting xpcshell to run on windows mobile and was excited to use my debugging tips from my last post. After dozens of attempts, I found that running python to launch processes (using osce.py) would not work when launched from Visual Studio debugger. So my debugging is limited to python output and sleep statements so I have time to read it.

Luckily launching other processes like fennec.exe or xpcshell.exe work great from the Visual Studio environment and I was able to get some progress on the reftests.

1 Comment

Filed under testdev

debugging in wince

In my challenge to bring Firefox automation to Windows Mobile, I have encountered many hurdles (such as getting the build to work, launching processes, using python and figuring out why my scripts are failing).  After mentioning this to some of my co-workers at the Mozilla all-hands, I was told you could run a program on a device from Visual Studio using the debugger.

As soon as I got to the office the next day, I setup and gave this a try.  In true hacker sense, I just fired up visual studio, created a new empty project and started poking around.  I started in project->settings, and found the “debugging” area where I could enter a program and arguments.  This part can be difficult as you need the full path to the program name and any arguments in the right (windows) format.

Next I found Tools->Connect to Device and Tools->Security Manager to get my device connected.  One of the keys here was to choose a real device in the device picker vs. an emulator (and of course have the device connected via active sync).  Ok, now I hit debug (F5) in Visual Studio, and I am debugging.

This took me about an hour to figure out with no tips, wiki, or google help.  The end result is I didn’t get all the debug information I would like to get, but I found a faster way to launch and get my error messages than any other method I used in the past.

1 Comment

Filed under testdev