Saturday, November 3, 2012

Manually Deleting the WebDriver Firefox Profile Directory

Some time ago, I starred a Selenium WebDriver bug that has a long discussion about how WebDriver leaves the Firefox profile directory behind in tmp after the profile goes away. Allegedly it was fixed at some point, but it still gets pinged from time to time, so who really knows.

Usually you will discover this when you are running a long set of tests that don't reuse the same Firefox, and then your hard drive fills up. This can be, well, a little frustrating. But on the long list of known WebDriver issues that never seem to really get fixed, this one is fairly minor, because it's simple to work around.

The comments in the bug suggest an @AfterClass method that uses Selenium's TemporaryFileSystem class to do the cleanup. This seems pretty satisfactory for most purposes. Nonetheless, depending on what else is going on behind the scenes, you may not want to clean out the entire Selenium-managed temporary directory in the middle of a test run.

I thought I would explain how we accomplish the same thing in WebTestingExplorer. We have a wrapper around the WebDriver instance that we use. It has a close() method that gets called between test cases. One of the things we do in that close() method is work around this bug:

    List<String> profileDirs = Lists.newArrayList("anonymous*webdriver-profile",
        "userprofile*copy", "seleniumSslSupport*");
    File tmpDir = new File(System.getProperty(""));
    FilenameFilter profileDirsFilter = new WildcardFileFilter(profileDirs);
    File[] files = tmpDir.listFiles(profileDirsFilter);
    for (File profileDir : files) {"Cleaning up tmp profile directory: " + profileDir.getAbsolutePath());
      try {
      } catch (IOException e) {
            "Failed to delete tmp profile directory: " + profileDir.getAbsolutePath(), e);

As you can see, we fairly strategically delete the things that we found Selenium and Firefox can create each time a new FirefoxProfile/FirefoxDriver gets instantiated. Theoretically, if this bug ever gets fixed-fixed, we could take this code out, but actually, I don't see any reason not to just leave it forever. It's better than having the issue regress on us.