New window handles disappearing in IE, can't work with new window

[Daniel Charles]

(FYI, I have also posted this issue on StackOverflow.)

I am using the latest version of Selenium (2.37.0) with C# in Internet Explorer 10 (using the latest 32-bit InternetExplorerDriver, 2.37.0) to log in to a webpage, click on a button that opens a new window, and then changes focus to the new window.

Originally I was using this code in Firefox, and it would work every time:

// Get handle for original window

string parentHandle = driver.CurrentWindowHandle;

// Click on button for new window

driver.FindElement(By.Id("buttonForNewWindow")).Click();

// Get list of all window handles

ReadOnlyCollection<string> allWindowHandles = driver.WindowHandles;

// Loop over all handles and switch to new child window

foreach (string handle in allWindowHandles)

{

    if (handle != parentHandle)

    {

        driver.SwitchTo().Window(handle);

    }

}

But this doesn't work in Internet Explorer.

I have pinpointed the problem. Before I open the new window, I use driver.WindowHandles.Count to get the number of window handles, and (as expected) it tells me that there is only one window handle. Then, when I click the button for the new window, it tells me (again, as expected) that there are two window handles. But before the code gets to the line for driver.SwitchTo().Window(handle);, the number of window handles has dropped back down to one, even though both windows are still visible.

So somehow one of the window handles is getting lost. I have confirmed (using a bunch of Console.WriteLine statements) that the window handle that is dropped is the new one. I also used the Stopwatch class to time how long it takes for the new window handle to be dropped:

Stopwatch sw = new Stopwatch();

// Wait until the number of windows has changed from 1 to 2

WebDriverWait wait = new WebDriverWait(driver, TimeSpan.FromSeconds(10));

wait.Until((_driver) => { return _driver.WindowHandles.Count != windowsBefore; });

// Start stopwatch

sw.Start();

int numberOfWindows = driver.WindowHandles.Count;

while (numberOfWindows == 2)

{

    numberOfWindows = driver.WindowHandles.Count;

}

sw.Stop();

Console.Write("\nTime elapsed: " + sw.ElapsedMilliseconds + " ms");

After running this a few times, I found that the number of window handles typically drops back to one in less than 50 milliseconds. However, one time the window handle lasted much longer; here are the original numbers:

Time elapsed: 47 ms

Time elapsed: 31 ms

Time elapsed: 47 ms

Time elapsed: 2861 ms

Time elapsed: 30 ms

I have also confirmed that this problem does not occur in Firefox. When I run the same code in Firefox, I find that the number of window handles changes from 1 to 2, and stays that way, as it should.

It seems that others are having this problem as well on StackOverflow. This person finds that when they open a new window and wait 1000 milliseconds, getWindowHandles() returns a value of 1 instead of 2. And this person here on the Google Group seems to be having the same issue.

My question: Given that the handle for a newly-opened window remains open for (typically) less than 50 milliseconds, what is the most efficient possible way to switch to a new window in Internet Explorer 10 with Selenium? Or is there something I should be doing differently to prevent new window handles from getting lost?

[Jim Evans]

I just want to point out here that though you've mentioned three people who claim to have similar problems (yourself and two others), none of them have included the source code for a set of HTML pages that would reproduce the system. Working with popup windows in the IE driver is not globally broken for all users of all websites everywhere. Without a set of HTML pages that reproduces the issue, it will be nearly impossible to provide any sort of a resolution. Please note that this set of pages does not need to be the exact application where you see the issue, simply one that works similarly enough to reproduce it.

[Daniel Charles]

Good point, Jim. If I find the time, I may try to come up with a sample webpage to try to figure out this problem.

[Daniel Charles]

Just in case anyone happens to come across this post: I've posted a follow-up here and on StackOverflow.

[Philip Robinson]

Hi Jim.

I have recently been dusting off and upgrading a very old Selenium testing project to use the "new" Selenium webdrivers, and encountered this issue using Python against IE 11.

My scripts are running normally for pressing buttons, accessing links, entering text, etc., but fail to recognise child windows opened by clicking on an application link.  The issue issue does seem to be related to the content of window_handles, and I have attached two files that minimally show the problem, with the number or entries in window_handles sometimes briefly showing 2 before dropping back to 1, while both the parent and child windows are still open.

I first encountered the error running against a normal intranet IIS web application, not on local files, but the attached local files exhibit the same behaviour.

As far as I can tell I have set up Selenium / Python / IE correctly.

The only thing that I'm not particularly sure about is the Protected Mode setting for each Zone.  IE Protected Mode Settings are locked down and this initially blocked my Selenium scripts from running at all.  I did NOT use the "flakiness" capability flag, but instead used a routine to poke registry settings to turn protected mode ON for all zones (https://stackoverflow.com/a/45619945).  I also tried turning OFF protected mode in all zones, but still have the same non-recognition of opened windows issue.

I am using the 32-bit IE webdriver, because the 64-bit version gave me a "Connection forcibly closed by remote host" error.  If necessary I can attempt to go back and get the 64-bit driver running.

Additional windows are recognised in Firefox just fine but unfortunately, for reasons, I must run this application in IE.

I hope that the attached files can help in identifying the cause of this issue, especially if the cause is something that I can fix locally.

Thanks for your great work,

Philip Robinson