Thursday, April 8, 2010

Firefox 3.6.3 and Selenium issue with FirefoxChromeLauncher$FileLockRemainedException: Lock file still present!

As part of development, we tend to use and write functional test cases using Selenium. The Selenium IDE integration with Firefox is seamless and it's very easy to record the user actions and just get the functional test case code out of it. With the latest version of Firefox 3.6.3, I've faced issue of "parent.lock" file on my Windows box and "parentlock" file on linux box with error
org.openqa.selenium.server.browserlaunchers.FirefoxChromeLauncher$FileLockRemainedException: Lock file still present!

The internet search was not proving to be useful and the Selenium Test cases are refusing to launch the Firefox browser because of this parentlock files. These files are getting created under the custom profile being prepared by firefox for each browser session and remains in that folder, if firefox is not properly closed. Also, on windows, I've found problem of Firefox process still running even if browser is closed and not getting closed automatically. You've to manually go to the Task Manager and kill the process of Firefox.

So, overall the situation was not good for the Selenium Test cases to run. The log was clearly indicating issue with Custom Profile and server jar. So, there must be some issue with it. If it'd have run on Linux and not on Windows, it'd have been easy for me to crib about Microsoft, but that was not the case here.

I had Selenium Server 1.0.1 jar, so I decided to digg into this jar.

Explode the jar in a location and digg through it, you'll find the restriction placed in this jar as...





{ec8030f7-c20a-464f-9b0e-13a3a9e97384}
1.4.1
3.5.*




Ahhh.... that seems to be the problem. I've gone ahead and edited "install.rdf" files under selenium-server-1.0.1-standalone.jar\customProfileDirCUSTFFCHROME to support max version as 3.6.*. The updated install.rdf file have contents as below...





{ec8030f7-c20a-464f-9b0e-13a3a9e97384}
1.4.1
3.6.*





Then just re-build the jar file and then just use the newly build jar file.

And whoilla !!! it seems to have worked smoothly on both Linux and Windows.

I'm sure this will be fixed in next releases of Selenium Server, but as of now, who are facing the issues with it, they can solve it by above method.

2 comments:

  1. Thanks, your solution worked for me as well !

    ReplyDelete
  2. Thank you, you saved my life.

    I was forced to use selenium grid 1.0.4, because that's the version used in the Hudson plugin.

    ReplyDelete