MarketWatch / UserZoom promote Google Chrome Monopoly

While reading an article on MarketWatch using Firefox Nightly I was prompted to fill out a user survey. I’ve stopped responding to most of these types of requests since they have become more of a data gathering exercise about me rather than actually attempting to find out what I think of the site itself. Since I like MarketWatch and haven’t seen this request before, I accepted the prompt this time and prepared to see what they wanted to know. Unfortunately, I was blocked by the following:

Unfortunately, the study owner or the system has restricted this device/browser for this study. In order to participate in the study please open this page from one of the following options: Desktop / Laptop * Google Chrome. Thank you for your cooperation.

Needless to say, I didn’t switch to Chrome to fill out their survey and now have a negative opinion of MarketWatch and UserZoom.

Update January 21

I did send in feedback to MarketWatch regarding the situation but did not receive a reply. Just now I visited again and received another prompt for a user survey and accepted in order to see if they had fixed the situation.

Close but no cigar.

I guess detecting Firefox is just too hard. For the record, my user agent string is Mozilla/5.0 (X11; Linux x86_64; rv:86.0) Gecko/20100101 Firefox/86.0

I recommend Browser detection using the user agent if you really must block browsers.

Autophone Status Update 2015-02-23

Autophone is one of the few test frameworks for measuring page load performance and testing video playback on real Android devices. Although Autophone failures will not cause checkins to the tree to be backed out, developers need to be aware of Autophone and how to respond when their patches have been identified as regressing Autophone.

Mozilla developers can find more information about Autophone, what the tests actually measure and how to run try builds against Autophone at Autophone for developers on

Much has changed in Autophone since my last update:

  • Moved to the Mountain View QA lab.
  • Tests Nexus S, Nexus 4, Nexus 5 and Nexus 7 (2013) devices.
  • Uses adb to issue commands to the devices rather SUTAgent.
  • Runs video related Mochitests
  • Submits test results to Treeherder and test logs to S3.
  • Supports testing try builds.
  • Tests mozilla-central, mozilla-inbound, fx-team, b2g-inbound, mozilla-aurora, mozilla-beta and mozilla-release respositories.

Future plans for Autophone include:

  • Support for job retriggers and cancels via the Treeherder UI.
  • Addition of Nexus 6 and Nexus 9 devices.
  • Replacement of the mac mini host with rack mounted linux servers.
  • Improved graphing solution to better support the increased number of repositories and devices.

Autophone bugs are filed under Testing:Autophone in bugzilla. If you have problems using Autophone or would like to make suggestions, please file an Autophone bug. If you would like to reach out directly, I am usually available on as bc in #ateam or #mobile.

How to work around SOAP request protocol error with VMware-vSphere-Perl-SDK-5.5.0

During a move from vSphere 5.0 to 5.5 I ran into errors using the Perl scripts provided with the VMware vSphere Perl SDK for 5.5 on Fedora 20. The symptom was the following response to calling

SOAP request error - possibly a protocol issue: <?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope xmlns:soapenc=""

I found the solution on the VMware communities at SOAP error with VMware-vSphere-Perl-SDK-5.5.0, but thought I would provide the additional steps I took in the hope it will help someone else.

The recommended solution was to use an older version of libwww-perl, in particular 5.837. But many of the packages on my system depend on libwww-perl and I didn’t want to mess with such a critical piece of my environment. The solution was to download the older version of libwww-perl, install it into a non-system location and to set the environment variable PERL5LIB to point to the new location before calling the vSphere Perl SDK scripts.

$ cd ~/Downloads/
$ mkdir libwww-perl
$ cd libwww-perl
# Download libwww-perl-libwww-perl-5.837.tar.gz from and save to ~/Downloads/libwww-perl
$ tar zxvf libwww-perl-libwww-perl-5.837.tar.gz
$ cd libwww-perl-libwww-perl-5.837
# Pick an installation location for libwww-perl which does not interfere with your system.
perl Makefile.PL INSTALL_BASE=install_location
make test
make install

Since I wrap calls to the VMware Perl SDK in bash scripts, all I needed to do to use libwww-perl 5.837 was to add the following at the beginning of the scripts:

export PERL5LIB=install_location/lib/perl5

Remember to change install_location to match your environment.

Hope that helps and thanks to the VMware community for the work around.

Splitting and Packing Android Boot images

After wandering twisty little passages, all alike concerning rooting Android devices I decided the best way forward for devices with unlocked bootloaders was to root via modifying the default.prop values in the boot image. There are a number of different scripts available on various sites which purport to unpack and pack Android boot images, but it seemed that the best approach was to go to the source and see how Android dealt with boot images.

I created spbootimg and pkbootimg from the official mkbootimg in order that it would properly handle official android boot images at least.


usage: spbootimg

spbootimg splits an Android boot image file into separate files:

* <bootimg-filename>-kernel – kernel
* <bootimg-filename>-first-ramdisk – ramdisk
* <bootimg-filename>-second-ramdisk – only created if it existed in the input boot image file.
* <bootimg-filename-header> – text file containing constants discovered in the boot image

You can download the source for spbootimg and pkbootimg and build it yourself. I don’t provide binaries because I do not wish people who do not understand the consequences of their actions to brick their devices.


usage: pkbootimg
--ramdisk --ramdisk-addr
[ --second <2ndbootloader-filename>] [ --cmdline ] [ --board ] [ --pagesize ] --second-addr

pkbootimg takes the output of spbootimg: a kernel file, a ramdisk file, an optional ramdisk file; and using the command line, board, page size and address information discovered in the original boot image, packs them into a new boot image which can be flashed onto a device using fastboot.


Looking at the source for adb.c, we see that at a minimum we need a build of adb where ALLOW_ADBD_ROOT was set and either of the following was set in the ramdisk’s default.prop:


service.adb.root=1 will result in adbd running as root by default. ro.debuggable=1 and service.adb.root=1 will allow you to run adbd as root via the adb root command.

If your device’s version of adb was not built with ALLOW_ADBD_ROOT set, you will need to build your own version and place it in the ramdisk at sbin/adbd.

Once you are able to run adb as root via adb root, you will be able to remount the /system/ directory as writable and can install anything you wish.


Some of the automation used in mozilla requires the use of a version of the su command which has the same command line syntax as sh. In particular, we require that su support calling commands via su -c "command args...". You can possibly build your own version of su which will run commands as root without access control or you can use one of the available “Superuser” apps which manage access to su and provide some degree of security. I’ve found Koushik Dutta’s Superuser to work well with Android up to 4.4.

If you use Koushik’s Superuser, you will need at least version and will need to make sure that the script is properly installed so that Koushik’s su runs as a daemon. This is automatically handled if you install Superuser.apk via a recovery image, but if you install Superuser manually, you will need to make sure to unpack Superuser.apk and manually install:

  • su to /system/xbin/su
  • to /system/etc/
  • Superuser.apk to /system/app/Superuser.apk

Simply No Excuse

Almost 13 years ago, I was a member of Netscape’s Technology Evangelism team tasked with helping promote a web based upon standards that could be accessed by anyone, using any browser on any operating system. Netscape is no more and the web is a much different place than it was in late 2000. In 2004 Firefox showed that alternative browsers were a reality and opened opportunities for others such as Apple’s Safari and Google’s Chrome. Apple and Google brought alternative devices such as smartphones and tablets to the web that were inconceivable in 2000.

Imagine my shock and dismay when I saw the headline from The Atlanta Journal-Constitution “Oregon exchange works with only one browser” in my Google Alert for Internet Explorer.

By limiting their web site to Internet Explorer, the State of Oregon forces their citizens to use not only Microsoft’s Internet Explorer, but also Microsoft’s Windows operating system. Users of Firefox, Safari, Chrome, OS X, or Linux are excluded from using a public web service to obtain a Federally mandated insurance policy.

There is simply no excuse for an Internet Explorer only web site to be developed in the 2013!

As I said over ten years ago:

The future belongs to developers and browsers which support standards. If you fail to take advantage of the coming change in browsers, your competitors will eat your lunch. Once that happens, the only place your web site will be found is on the web archive.