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("java.io.tmpdir")); FilenameFilter profileDirsFilter = new WildcardFileFilter(profileDirs); File[] files = tmpDir.listFiles(profileDirsFilter); for (File profileDir : files) { LOGGER.info("Cleaning up tmp profile directory: " + profileDir.getAbsolutePath()); try { FileUtils.deleteDirectory(profileDir); } catch (IOException e) { LOGGER.log(Level.WARNING, "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.