Tag Archives: tips

notes on a python webserver

Last week I created a python webserver as a patch for make talos-remote.  This ended up being frought with performance issues, so I have started looking into it.  I based it off of the profileserver.py that we have in mozilla-central, and while it worked I was finding my tp4 tests were timing out.

I come to find out we are using a synchronous webserver, so this is easy to fix with a ThreadingMixIn, just like the chromium perf.py script:

class MyThreadedWebServer(ThreadingMixIn, BaseHTTPServer.HTTPServer):

Now the test was finishing, but very very slowly (20+ minutes vs ❤ minutes).  After doing a CTRL+C on the webserver, I saw a lot of requests hanging on log_message and gethostbyaddr() calls.  So I ended up overloading the log_message call and things worked.

class MozRequestHandler(SimpleHTTPServer.SimpleHTTPRequestHandler):
    # I found on my local network that calls to this were timing out
    def address_string(self):
        return "a.b.c.d"

    # This produces a LOT of noise
    def log_message(self, format, *args):

Now tp4m runs as fast as using apache on my host machine.


Filed under testdev

Professional Development, Improv and your audience

I had the opportunity to attend some really exciting professional development sessions at the All Hands.  Personally I found these very interesting, but I heard a lot of grumbling about how these are not adding a lot of value or of interest.

One reason I found these interesting is that in a previous life I had attended a few years of Improv acting classes and did a short stint of real onstage Improv acting.  In looping back to these professional development sessions, they reminded me of the core concepts we learned in Improv 101.  So if you felt that you missed out, sign up for an Improv class.  Maybe if there are professional development sessions at a future event they could just have an Improv acting class.

Related to the professional development courses, I found that most of these were sparsely attended.  Of those that did attend the courses received great reviews/ratings.  To be fair, the technical tracks that I attended had about the same attendance records of the professional development tracks.  Maybe we are not creating sessions that are of interest to our audience?  I know for the technical tracks we just propose something and it magically becomes a session.  I don’t recall getting any input in what sessions would be available to me.  Maybe in the future we can do a better job of getting input from the community (a.k.a audience)!

1 Comment

Filed under general, reviews

More info on the localhost->mochi.test change

This is just another public service announcement about the upcoming change to the unit tests. Last week I wrong about ‘mochi.test is the new localhost’, and this week I am reiterating that with more details.

After some feedback on the bug for this, we now have these options available:
* mochi.test
* moztest

With these options for referencing data in a test, you should be able to cover all the different networking scenarios that need testing. Keep in mind that mochi.test is the primary host and if you are posting a message to the parent window, the default domain is mochi.test, not localhost.

There is one other scenario where you need to get the real ip address of the server and this can be done with code like this:
var ios = Cc[“@mozilla.org/network/io-service;1”].getService(Components.interfaces.nsIIOService);
var pps = Cc[“@mozilla.org/network/protocol-proxy-service;1”].getService();
var uri = ios.newURI(“http://example.com”, null, null);
var pi = pps.resolve(uri, 0);
var host = “http://” + pi.host + “:” + pi.port;

From all the tests, test_prompt_async is the only test that needs this type of solution.

When we start running tests on windows mobile using the remote webserver, there won’t be any other changes needed other than what is mentioned above. Look for a demo from Clint at an upcoming Monday meeting.

Leave a comment

Filed under qa, testdev

running httpd.js on a remote host

This exercise came about as an option for running unittests on windows mobile. We ran into an issue where the http server was running but not returning web pages. Vlad had mentioned running the web server on a host machine to be respectful of the memory on the device. In the past other members of the QA team have tried this with no luck. With the help of :waldo, I was able to get tests running while accessing a remote webserver.

For a quick background, all unittests rely on httpd.js running via xpcshell to serve web pages. For example, xpcshell update tests (test_0030_general.js) utilize httpd.js to download a .mar file and mochitest uses httpd.js for every test it runs. It is a little tricky to get this to run on a remote server as there are a few things to edit:

Now you need to fire up xpcshell to run as a server:

#set any env variables such as
#LD_LIBRARY_PATH=$firefox_dir/xulrunner on linux
cd $firefox_dir/xulrunner
./xpcshell -f ../../mochitest/httpd.js -f ../../mochitest/server.js

On the remote machine launch your test and be happy!

To really utilize this for the Fennec unittests on Windows Mobile, we will have to make many changes to the tests in addition to the ones mentioned above. Making it fit into automation would be very difficult as ip addresses can change and we might need to set it dynamically. Alternatively, running 1 host to many clients does have some attraction.


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:

– 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

– 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

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.


Filed under testdev

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