FirefoxDriver getWindowHandles sometimes returns an empty string as a window handle

[juangj]

I've noticed that ClickTest.testShouldOnlyFollowHrefOnce fails sometimes (but at a very low rate) because it closes the original window instead of the newly-opened window.

Specifically, this switchTo() doesn't work, so the following close() closes the "main" window, and additionally causes the switchTo() in the finally block to fail, resulting in an error like this:

java.lang.RuntimeException: org.junit.internal.runners.model.MultipleFailureException: There were 2 errors:
org.openqa.selenium.NoSuchWindowException(Unable to locate window "{a46823e9-4fa9-46de-8663-5e44cf4b2a67}"
Command duration or timeout: 2.13 seconds)
org.openqa.selenium.NoSuchWindowException(Window not found. The browser window may have been closed.
Command duration or timeout: 73 milliseconds)

From adding some logging, what's happening when the test fails is that getWindowHandles() returns two handles, one of which is the empty string. That empty string is returned by the FirefoxDriver here if win.top.fxdriver doesn't exist.

Calling getWindowHandles() again a short time later always yields two non-empty window handles.

Giving the new window a name by modifying the JS window.open call here doesn't seem to eliminate occurrences of this empty string, so perhaps this is happening if the new window hasn't finished loading yet?

A couple possible solutions that may or may not be any good (but each of which fixes the flakiness in my testing):

1. Modify WaitingConditions.newWindowIsOpened to ignore the empty string if it's returned from getWindowHandles(). This works because the FirefoxDriver (usually on one of the next 1-2 calls to getWindowHandles) will eventually return a "real" window handle.
2. Have FirefoxDriver ignore windows with empty names in getWindowHandles(); I suspect this isn't a great idea, because it is legal for a window name to be the empty string.
3. Don't even return window names from getWindowHandles() -- just eliminate that branch completely; I'm not familiar with the history of the code or why the driver does this (though it has done it since at least 2009, per git blame) but I'd be curious to understand why it wouldn't work. Are there ways to create windows for which win.top.fxdriver.id will never exist, necessitating some other way of referencing the window?
4. Do option Please accept this documentation update #1 in my own copy of the code and wait for Marionette to arrive ;)

As one more footnote, I don't think I've seen this failure mode in [http://ci.seleniumhq.org:8080/](Selenium's Jenkins CI), but when I'm running the tests locally, the local and remote ends are both on the same machine (which isn't the case for the CI, AFAIU), so the low latency of sending commands to the browser might tickle the bug.

[juangj]

@barancev: @sevaseva suggested you're the best person to ask about FirefoxDriver's behavior in this circumstance.

[jleyba]

I vote for eliminating the branch. Returned window handles should be opaque IDs generated by the server, not window.name (which is a mutable value anyway)

[jleyba]

re: your footnote

Everything on the CI runs against SauceLabs browsers

[barancev]

+1 to get rid of the branch that returns something for a window without the driver attached.