Bug in the FirefoxLauncher.java?

[Scott Hamilton]

I was trying to use the rake install-firefox process to install a
WebDriver profile for Firefox on a new machine, and while the
installation succeeded in practice, it left the FF browser window
open. In looking at the code, it looks like there were some odd ports
being referenced in trying to perform this operation. Below is an SVN
patch if you think this looks right that seemed to fix it locally for
me.

Thanks!
Scott

Index: FirefoxLauncher.java
===================================================================
--- FirefoxLauncher.java (revision 671)
+++ FirefoxLauncher.java (working copy)
@@ -93,7 +93,7 @@

while (System.currentTimeMillis() < maxWaitTime) {
try {
- connection = new RunningInstanceConnection
("localhost", port, 1000);
+ connection = new RunningInstanceConnection
("localhost", port, FirefoxDriver.DEFAULT_PORT);
Thread.sleep(2000);
connection.quit();
return;
@@ -109,7 +109,7 @@

protected void connectAndKill(int port) {
try {
- ExtensionConnection connection = new
RunningInstanceConnection("localhost", port, 5000);
+ ExtensionConnection connection = new
RunningInstanceConnection("localhost", port,
FirefoxDriver.DEFAULT_PORT);
connection.quit();
} catch (ConnectException e) {
// This is fine. It just means that Firefox isn't running
with the webdriver extension installed already

[Simon Stewart]

Hi Scott,

Thanks for pointing this out, I'll make the fix on Monday to trunk. It
also provides the perfect excuse to talk about some of the changes
that we've been making. :)

First off, unless you're working on the WebDriver codebase itself,
there should be no need to run "rake install_firefox": the JAR
contains a prepackaged profile and uses that by default. In fact, the
only way to force the use of the existing WebDriver profile is to do
so explicitly:

WebDriver driver = new FirefoxDriver("WebDriver");

This resolves a long-standing source of frustration with early
adopters of the project. When we started, you had to install the
profile by hand because we'd not written the code to extract an
existing profile, and we'd not yet figured out how to "clean" a
profile so that we could share it between firefox 2 and 3. By using
the packaged profile, we can make changes to the communication
mechanism (for example) without worrying that we might be breaking
someone's build.

If you're a WebDriver developer, you shouldn't need to run "rake
install_firefox": the tests now pick up the version to use from the
current working directory. This is exteremly useful if you want to
work on multiple versions of the codebase at the same time (and you're
not using something like gitsvn)

I'm tempted to remove "install_firefox" entirely, since the two main
use-cases for it are now gone. Other than the fact that the wiki will
need to be updated, can anyone think of a reason to keep the target?

Regards,

Simon

[Simon Stewart]

Hi Scott,

I've just tried the "rake install_firefox" target on my local machine,
and it works as expected. The final argument in the methods calls we
could have modified is the timeout, so we probably don't want to mess
with it. I'm not quite sure why your browser instance was hanging.

Regards,

Simon

On Fri, Jan 9, 2009 at 8:57 PM, Scott Hamilton
<scottha...@gmail.com> wrote:
>

[Scott Hamilton]

You might very well be right - I will take a closer look again when I
get a chance.

The odd thing is that once I made these changes, however, the browser
closed appropriately.

On Jan 12, 6:49 am, "Simon Stewart" <simon.m.stew...@gmail.com> wrote:
> Hi Scott,
>
> I've just tried the "rake install_firefox" target on my local machine,
> and it works as expected. The final argument in the methods calls we
> could have modified is the timeout, so we probably don't want to mess
> with it.  I'm not quite sure why your browser instance was hanging.
>
> Regards,
>
> Simon
>
> On Fri, Jan 9, 2009 at 8:57 PM, Scott Hamilton
>

[Scott Hamilton]

You're absolutely right, I failed to look deep enough to see that
these were indeed timeouts. Sorry about the false alarm.

As for why it started working, I wonder if perhaps we have an issue
where the current timeout there (1000 milliseconds) was insufficient
for the FF profile to be installed/configured/processed/whatever on my
particular machine, and the default port value gave me 7 seconds which
gave it enough time... I realize by looking at the code that even the
1 second should have worked by trying again for 60 seconds, but for
some reason it did not.

Incidentally, I tried this again with the latest code and it works
fine as is.

As for your statement about maybe not needing this, I wonder... If I
understand you right, the impact of not having a specific profile
encoded is that a profile will be created on the fly for me. But if
we do this, and are running a series of tests driven by jUnit for
instance, wouldn't this incur a lot of extra overhead, such that we'd
want to have a persistent profile to reference anyway?

[Simon Stewart]

Hi Scott,

There is overhead incurred anyway: each "new FirefoxDriver()" makes a
duplicate of a template profile (either the one you supplied, or an
auto-generated one) This is done so that each instance of firefox is
completely isolated from the other ones. I've not measured the
difference, but my impression is that both of these take a similar
amount of time. I could be wrong :)

Cheers,

Simon