One of the things that you can do with Firefox that you can’t do with other browsers [or at least not as nicely…] is do a run using a profile that has custom settings already in place (cookies, extensions, local storage, etc.). A couple people have asked for it, and someone then someone paid for it to happen. Of course, it was a much deeper rabbit hole than I thought and I under-quoted them. Ah, well…

Because Py.Saunter and SaunterPHP are designed to be self-contained checkouts, all profiles will be in the support/profiles directory off of the Saunter project directory. So if you have 3 different profiles that you want to use, you would end up with

  • support
    • profiles
      • blue
      • orange
      • green

Py.Saunter

Selenium-RC – Local

This configuration is the easiest to setup; simply checkout your Saunter project onto the machine you are going to run the Selenium server on and start it with the -firefoxProfileTemplate <dir> flag. That’s it. Now, when Firefox lights up it will use that profile rather than a newly constructed one.

Selenium-RC – Sauce OnDemand

This is slightly more complicated, but not by too too much. Obviously one cannot checkout local copies one their VMs, but we can send it over the wire to them. Or more accurately, Saunter can thus saving you a fair bit of pain. Not that there isn’t a hoop or two that needs jumping through…

In your saunter.ini file you need to use one of two configuration options, but other which are in the Selenium section of the config.

  • profile: name_of_profile
  • profile-<platform>: name_of_profile

There is a bit of ordering at play. If you have a matching platform key per sys.platform then it will use that rather than the generic one. For instance,

<pre lang="text">[Selenium]
profile: red
profile-darwin: blue

would use the blue profile on OSX, but red on Linux.

Because Se-RC doesn’t have the notion of sending a profile over the wire, we need to enable Sauce Labs to get it. This is done by telling them where to find an HTTP server with it which we do in the saunter.ini as well.

<pre lang="text">[YourCompany]
file_server_base: s3cr3t.element34.ca:7000

Note: if this server is not accessible from the internets then you need to setup a Sauce Connect tunnel to access it.

WebDriver

WebDriver nicely has profile support baked into the wire protocol, so there is nothing magical do whether running locally or in the Sauce cloud aside from the saunter.ini entries mentioned above.

SaunterPHP

The same configuration process applies for SaunterPHP as Py.Saunter. The exception is [for now] how it is configured.

<pre lang="php">$GLOBALS['settings']["profile"] = "red";
$GLOBALS['settings']["profile-darwin"] = "blue";

Caveats

So it turns out that the Firefox ‘portable’ profile story isn’t actually that portable a story. Or at least in one edge case I stumbled on — but its a crazy useful edge case if it worked. Firefox profiles contain the extensions that they use; things like Firebug and company. These are written in JS/XUL and are generally pretty cross-platform portable. Unfortunately, what profile do not contain are addons — flash and silverlight are two examples of addons. What the profile has instead an arcane, generated config file that if you edit in just the right way you can control the behaviour of these things. Except that the file includes both the path on disk (which means it is not cross platform) and the version of the addon (which means even if you are on the same OS but on differently patched machines you are screwed).

Of course, you are managing the configuration of the machines in your farm with something like Puppet so all your configurations are the same so you can make a profile on each target platform. Thus the profile-<platform> option. Its not that simple in the case where you don’t control the machines, like, say, the Sauce Cloud … but I have been suggested a solution around that and just need the time to experiment with it.