There a couple of things which you have to take care while dealing with InternetExplorer as follows :
As you mentioned There is a known issue with selenium documented in GitHub, these are not issues as such but is the combined set of Required Configuration while dealing with InternetExplorer. Without taking care of these settings InternetExplorer may not behave as per expectation. The following items are critical to demonstrate proper behavior of InternetExplorer v11 :
Enhanced Protected Mode must be disabled for IE 10 and higher. This option is found in the Advanced tab of the Internet Options dialog.- The browser
Zoom Level must be set to 100% so that the native mouse events can be set to the correct coordinates.
- You have to set
Change the size of text, apps, and other items to 100% in display settings.
For IE 11, you will need to set a registry entry on the target computer so that the driver can maintain a connection to the instance of Internet Explorer it creates.
For 32-bit Windows installations, the key you have to look in the registry is :
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\Main\FeatureControl\FEATURE_BFCACHE
For 64-bit Windows installations, the key is :
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Internet Explorer\Main\FeatureControl\FEATURE_BFCACHE
The FEATURE_BFCACHE subkey may or may not be present, and should be created if it is not present.
Native Events : The advantage of using native events is that it does not rely on the JavaScript sandbox, and it ensures proper JavaScript event propagation within the browser. However, there are currently some issues with mouse events when the IE browser window does not have focus, and when attempting to hover over elements.
Browser Focus : IE itself appears to not fully respect the Windows messages we send the IE browser window (WM_MOUSEDOWN and WM_MOUSEUP) if the window doesn't have the focus.
You can find a detailed discussion on Native Events and Browser Focus here.
Now, you have to configure all these parameters through DesiredCapabilities Class as follows :
DesiredCapabilities cap = DesiredCapabilities.internetExplorer();
cap.setCapability("ignoreProtectedModeSettings",1);
cap.setCapability("IntroduceInstabilityByIgnoringProtectedModeSettings",true);
cap.setCapability("nativeEvents",true);
cap.setCapability("browserFocus",true);
cap.setCapability("ignoreZoomSetting", true);
cap.setCapability("requireWindowFocus","true");
cap.setCapability("INTRODUCE_FLAKINESS_BY_IGNORING_SECURITY_DOMAINS", true);
As per Best Programming practices Thread.sleep(1000); is a huge No as it degrades the Test Performance
Now, as you are aware that the Browser Clients lags the WebDriver instance so we have to often sync up them. So before you collect the windowHandles you have to induce WebDriverWait as follows for which you can find a detailed discussion here :
WebElement popup= driver.findElement(By.name("popup"));
popup.click();
new WebDriverWait(driver,5).until(ExpectedConditions.numberOfWindowsToBe(2));
Set<String> windowHandles = driver.getWindowHandles();
System.out.println(windowHandles);
Update
I can see from your comments :
"Enable Enhanced Protected Mode" is unchecked in IE options. – Renjith Jan 9 at 7:26
Here is the exert from @JimEvans sensetional blog on Protected Mode settings and the Capabilities hack where @JimEvans nails the context in a clear and unambiguous term :
When the rewritten IE driver was first introduced, it was decided that it would enforce its required Protected Mode settings, and throw an exception if they were not properly set. Protected Mode settings, like almost all other settings of IE, are stored in the Windows registry, and are checked when the browser is instantiated. However, some misguided IT departments make it impossible for developers and testers to set even the most basic settings on their machines.
The driver needed a workaround for people who couldn't set those IE settings because their machine was overly locked down. That's what the capability setting is intended to be used for. It simply bypasses the registry check. Using the capability doesn't solve the underlying problem though. If a Protected Mode boundary is crossed, very unexpected behavior including hangs, element location not working, and clicks not being propagated, could result. To help warn people of this potential problem, the capability was given big scary-sounding names like INTRODUCE_FLAKINESS_BY_IGNORING_SECURITY_DOMAINS in Java and IntroduceInstabilityByIgnoringProtectedModeSettings in .NET. We really thought that telling the user that using this setting would introduce potential badness in their code would discourage its use, but it turned out not to be so.
If you are able to set the Protected Mode settings of IE, and you are still using the capability you are risking the stability of your code. Don't do it. Set the settings. It's not that hard.
Here is how you need to set the Protected Mode settings :
![Protected Mode IE]()
