Category Archives: Mozilla

I work for Mozilla Corporation

Linux Qt builds of Firefox now being generated

I just wanted to write a quick blog post to let everyone know that we are now producing Linux Firefox builds using the Qt widget set. Specifically, we are compiling against Qt 4.6.2 from Nokia’s LGPL SDK bundle. Unfortunately, the default theme is not working so it might be a little tough to make use of this as your main browser. As suggested by romaxa, installing a theme from addons.mozilla.org should get a working browser. These builds are bleeding edge and are likely to contain bugs, so as usual, your mileage may vary. I’d also like to thank Oleg (romaxa) for the help in getting the SDK sorted out!

Two outstanding issues are a lack of unit test coverage and no nightly builds. I have filed some bugs to rectify this:

  • 623740 – run unit tests (only mochitest?) on Linux QT builds
  • 623738 – deploy qt environment to linux testing slaves
  • 623735 – generate nightly linux qt builds

In case you don’t happen to have a machine around that can run these builds but want to see it live in action, here are some pictures

Firefox using Qt 4 showing about:buildconfig

Firefox using Qt 4 showing about:buildconfig

Firefox using Qt rendering the Acid2 test

Firefox using Qt rendering the Acid2 test

Update: the builds are on the ftp server if you are curious.

Nokia N900 unit tests and talos on Try!

If you’ve ever wanted to get on-device performance and unit test results for the Nokia N900 running fennec for your try push, today is your lucky day.  I have landed a patch that runs all unit test and performance suites that are running for Mozilla Central + Mobile Browser against your try build.  There are a couple things that are left to do, namely email notifiers and try chooser support.  Currently, emails aren’t being sent out for any result (pass, fail, warnings) on these tests.  Because of this, you will have to use Tinderbox or TinderboxPushlog to figure out the status of your build.  This is being tracked in bug 610574 and should hopefully be resolved soon.

A more challenging issue to solve is the lack of TryChooser support.  If you don’t know what TryChooser is, and you use the try server, I urge you to read this document and use it.  TryChooser helps us keep wait times and end-to-end times low and makes sure we don’t waste resources on results you don’t need/want.  Currently, if you ask for ‘maemo5-gtk’ builds to happen, you will get a full run of talos and unit tests regardless of whether or not you ask for them in your commit message.  The root of this problem is that our N900s run on very different configurations than our desktop Firefox testing machines.  It is more work to add TryChooser to the current mobile configurations than it would be to switch the N900s to the standard testing infrastructure.  As that is the direction we are heading, I am going to incorporate the TryChooser fixes into that project.

There are going to be some tests (Tzoom and some unit tests) that are orange some (or all) of the time.  These aren’t specific to try and I am sure that the mobile team would love any help you can offer in getting those tests green!  I can also hide those columns if they become a nuisance

Snippet from a TinderboxPushlog run

Snippet from a TinderboxPushlog run

Headers from Tinderbox showing the green performance tests

Headers from Tinderbox showing the green performance tests

Some dots from lots of different tests

Some dots from lots of different tests

Mobile on the new try server!

Mobile support for the new try server has just landed!  Any push after now will have an Android, Maemo 4, Maemo5 GTK and Maemo5 QT build done.  I have also added support for two magic files ‘mobile-repo’ and ‘mobile-rev’. Both of these files should be in the root directory of your mozilla-central clone.  The ‘mobile-repo’ file should contain a string with no whitespace or newlines that is a path relative to http://hg.mozilla.org/ referencing a mobile-browser repository. The ‘mobile-rev’ file should contain anything that can be used with the –rev flag to mercurial. In-repo branches or changeset identifiers work great here. Just like on desktop try, you can also have a special mozconfig for your mobile platforms. In the top level directory, create a mozconfig-extra file which contains options that are added to *all* platforms and a mozconfig-extra-android-r7, mozconfig-extra-maemo4, mozconfig-extra-maemo5-gtk and/or mozconfig-extra-maemo5-qt. I could add a check for a mozconfig-mobile that would add things to all mobile builds if that is desired.

An example of a push to try session to build against my user repository copy of mobile-browser might look like:

hg clone http://hg.mozilla.org/mozilla-central
cd mozilla-central
rm README.txt
echo 'users/jford_mozilla.com/mobile-browser' > mobile-repo
echo 'default' > mobile-rev
hg add mobile-repo mobile-rev
hg commit -m 'Testing to see if we build without a readme file'
hg push -f ssh://hg.mozilla.org/try

With this marks the end of the old try server. It also means that we have fully transitioned our try server build infrastructure to Buildbot 0.8.0.

Figuring out which files are touched while installing software

We are working on getting our infrastructure up to speed for Maemo 5 and Maemo 5 QT builds. A critical part of Maemo5 building is the scratchbox. This is a toolkit that Nokia uses to make development on for their linux based phones easier. We have enough linux build slaves in production that it is impractical to deploy scratchbox by hand on each machine. Scratchbox also does internet package downloads which means that we could get different packages each time we try to install the scratchbox. We already have a fairly old version of scratchbox which is set up with the Chinook sdk that we have used for doing our Maemo builds thus far. Originally I was under the impression that we were going to need to have 2 totally seperate scratchbox installations but thanks to Doug T. for showing me how to upgrade our existing scratchbox 4 installation to scratchbox 5.

My concern with this upgrade, however, was that files outside the /builds/scratchbox directory were going to be touched. I wanted to be thorough so I did an experiment. I ran find -mount -type f -exec openssl md5 '{}' \; | tee -a /file-list ; find -mount -type f -exec openssl md5 '{}' \; | tee -a /file-list before and after the scratchbox upgrade. The -mount and two different runs at our two mountpoints was to ensure that we didn’t hash things like the /dev, /proc, /sys filesystem. My original intent was to do diff file-list1 file-list2 but that resulted in showing me every single file that changed. I only wanted to know the files that changed outside of my scratchbox root directory of /builds/scratchbox. My diff was polluted by 77,000 files that resided in the scratcbox root. I figured that the best option at the time was to hack up a quick python script:

#!/usr/bin/python
#This file is a quick script to process the output of
# find / -mount -type f -exec openssl md5 '{}' \; | tee -a
import sys, os.path, re

if not len(sys.argv) == 3:
    print "purple monkey dishwasher"
    exit(1)
filename_a = sys.argv[1]
filename_b = sys.argv[2]
if not os.path.exists(filename_a) or not os.path.exists(filename_b):
    print "insert change into meter and press green button"
    exit(1)
data={}
pattern = re.compile("^MD5\((?P.*)\)= (?P.*)$")
#Get the data from A
f = open(filename_a, 'r')
for i in f.readlines():
    m = pattern.search(i)
    data[m.group('file')] = m.group('hash')
f.close()
f = open(filename_b, 'r')
sbfile = re.compile("^/builds/scratchbox") #pattern describing files to ignore
#Figure out diff to B
f = open(filename_b, 'r')
for i in f.readlines():
    m = pattern.search(i)
    if not data.has_key(m.group('file')):
        if not sbfile.search(m.group('file')):
            print 'new file - ', m.group('file')
    else:
         if not sbfile.search(m.group('file')):
             if not data[m.group('file')] == m.group('hash'):
                 print 'updated file - ', m.group('file')

This is code I have written to scratch my own itch. I am posting this as it might be useful to someone else. if you wanted to ignore a different directory you’d change sbfile = re.compile("^/builds/scratchbox") to be a pattern describing your path to ignore. If you wanted to find all things that changed over your whole partition you would remove sbfile and all sbfile checks to have a final bit of code like

#Figure out diff to B
f = open(filename_b, 'r')
for i in f.readlines():
    m = pattern.search(i)
    if not data.has_key(m.group('file')):
        print 'new file - ', m.group('file')
    else:
         if not data[m.group('file')] == m.group('hash'):
             print 'updated file - ', m.group('file')

In the end, I found that the scratchbox upgrade that I did only changed my bash_history and added some tarballs to /tmp. I am very glad that this is the case as it really simplifies our deployment of the new scratchbox!

What is wrong with AT&T’s Flash Ads?

Over the last couple days I noticed my Firefox getting painfully slow. The weird part was that the rest of my system was responsive. When I opened Activity Monitor it showed 100% CPU usage for Firefox. I decided to do some investigating. I used the ‘Sample Process’ feature in Activity Monitor.  After setting the display to ‘Percent of Parent’ I noticed that there was a lot of ‘Flash_EnforceLocalSecurity’ messages which lead me to believe that Flash was the culprit.
Screen shot 2009-11-24 at 3.01.37 PM
I went through my tabs, and sure enough I had lots of Flash open. This pattern kept repeating itself. I’d notice Firefox getting sluggish, close flash web pages and see Firefox performing properly and CPU usage levels back to normal. I found it strange that I could play Hulu and Youtube videos fine. I even went to www.bannerserver.com and found that while Firefox was never using 100% of my CPU. This was baffling me until I figured out what the problem was. This issue only happens when AT&T Uverse flash ads show up.

Screen shot 2009-11-24 at 2.31.55 PM
Not everyone cares to find the root cause of a problem like this. It is also only sporadically reproducible, going to the same website might show different ads each time. I would bet that a lot of people would look at this and say “Firefox is slow”, especially because the ads are there on many different pages.  These ads are also not the primary reason someone goes to the page (I’d hope) which means that it is difficult to associate the flash ad with the purpose of their tab if they do try to figure out what the problem is. Having plug-ins in a separate process (Electrolysis) seems like a great idea. I hope that, like Safari on Mac, it shows up as a totally separate process which helps avoid people blaming Firefox for poor performance.

Screen shot 2009-11-24 at 2.48.29 PM
The most annoying part of this whole situation is that I’d love to be a Uverse subscriber.  It is bad enough that they aren’t offering it in my area, but to make my browser slower is a slap in the face!