We Keep Coding

NoSuchWindowException - Unable to find element on closed window in Selenium on IE in spite of following the configuration advice in other answers

This is related to my other recent question on Selenium (that question was about a Firefox-specific issue, this one is about an IE-specific issue).
Basically, when I ran the following code
ieDriver.Navigate().GoToUrl("http://localhost:51282");
IWebElement linkToAboutPage = ieDriver.FindElement(By.Id("test"));
linkToAboutPage.Click();
to simulate clicking on a link, it successfully navigates to the page but when it tries to retrieve the actual element I get the following exception:
An exception of type 'OpenQA.Selenium.NoSuchWindowException' occurred in WebDriver.dll but was not handled in user code
Additional information: Unable to find element on closed window
The accepted answer to this question suggests that "Enable Protected Mode" in IE Security Settings should either be all selected or all unselected. Indeed, when I look at these settings, "Enable Protected Mode" is unselected for Intranet but not for the others:
Unfortunately, as the screenshot shows, that's being managed by my corporate IT department and I'm not sure that I'll have much luck convincing them to let me change the settings. I was also unable to edit my registry in the way suggested by some of the other answers (presumably due to the lack of administrative rights).
Some of the other solutions I've seen include setting IntroduceInstabilityByIgnoringProtectedModeSettings to true, providing a InitialBrowserUrl, or setting EnsureCleanSession to true. As shown below, I'm currently doing all of those things:
var ieOptions = new InternetExplorerOptions()
{
InitialBrowserUrl = "http://www.google.com",
IntroduceInstabilityByIgnoringProtectedModeSettings = true,
IgnoreZoomLevel = true,
EnableNativeEvents = true,
EnsureCleanSession = true
};
ieDriver = new InternetExplorerDriver(ieOptions);
ieDriver.Manage().Timeouts().ImplicitWait = new TimeSpan(0, 0, 10);
However, I'm still having the exact same problem.
Is there something else I can try that doesn't involve me bugging corporate IT for policy exceptions?
Perhaps significantly, this only happens when I'm running on localhost (which is a problem because that's where I intend to do most of my testing).

I found that setting the InitialBrowserUrl capability to the starting URL you want to navigate to, paired with IntroduceInstabilityByIgnoringProtectedModeSettings = true, works for me.
var ieOptions = new InternetExplorerOptions()
{
InitialBrowserUrl = <your-starting-url>
IntroduceInstabilityByIgnoringProtectedModeSettings = true,
...
};
Unfortunately I don't have a reason as to why this works, so this "fix" might simply be anecdotal...
Here's some other solutions you can try (from the official reference):
Required Configuration
The IEDriverServer exectuable must be downloaded and placed in your PATH.
On IE 7 or higher on Windows Vista or Windows 7, you must set the Protected Mode settings for each zone to be the same value. The value can be on or off, as long as it is the same for every zone. To set the Protected Mode settings, choose "Internet Options..." from the Tools menu, and click on the Security tab. For each zone, there will be a check box at the bottom of the tab labeled "Enable Protected Mode".
Additionally, "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.
For IE 11 only, 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 must examine in the registry editor 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. Please note that the FEATURE_BFCACHE subkey may or may not be present, and should be created if it is not present. Important: Inside this key, create a DWORD value named iexplore.exe with the value of 0.
Reference:
https://github.com/SeleniumHQ/selenium/wiki/InternetExplorerDriver#required-configuration

Values in registry do not always commit - Use Automatic Configuration Script

So, I have a task to:
1. Delete all settings in Internet Connection Properties
2. Set Use Automatic Configuration Script to my script
This is my code, and sometimes it works and values are in IE, and sometimes values are not in IE. I am frustrated with this hectic behavior and wondering where is my error (not in DNA ;))
RegistryKey registry = Registry.CurrentUser.OpenSubKey(
"Software\\Microsoft\\Windows\\CurrentVersion\\Internet Settings", true);
registry.SetValue("ProxyEnable", 0);
registry.Close();
RegistryKey registry2 = Registry.CurrentUser.OpenSubKey(
"SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Internet Settings\\Connections", true);
registry2.DeleteValue("DefaultConnectionSettings", false);
registry2.Close();
RegistryKey registry3 = Registry.CurrentUser.OpenSubKey(
#"Software\Microsoft\Windows\CurrentVersion\Internet Settings", true);
registry3.SetValue("AutoConfigURL", #"http://wwwwwwwww/configscript.pac", Microsoft.Win32.RegistryValueKind.String);
registry3.SetValue("ProxyEnable", 000000, RegistryValueKind.DWord);
registry3.Close();

I suspect that the issue you face has something to with stale values on the UI.
The quickest way to check whether your settings are "sticky" is to open Internet options and going to Lan settings directly from control panel.
The following command will launch "internet options"
control inetcpl.cpl
Further if your machine belongs to some corporate domains, there might be group policies set by admins that periodically enforces some values for these parameters.
In such cases, you might have to schedule a task for say every 10 minutes, and enforce values of your choice. (note: that is what I have been doing for quite some time)

Failed to perform action on hidden control exception

I am trying to create a UI test in VS 2010 using IE 9 in IE 8 compatibilty mode however when trying to record an action recording many of the steps fail. Then when I manually code in the missing steps and try to fill in a log in form with a username and password I get an exception that says I have failed to perform an action on hidden control.
The UI Test code:
public void Recordedmethod()
{
BrowserWindow uILogInWindowsInternetWindow = this.UILogInWindowsInternetWindow;
HtmlHyperlink uILogInHyperlink = this.UILogInWindowsInternetWindow.UIHomePageDocument.UILogInHyperlink;
HtmlEdit uIUsernameEdit = this.UILogInWindowsInternetWindow.UILogInDocument1.UIUsernameEdit;
HtmlEdit uIPasswordEdit = this.UILogInWindowsInternetWindow.UILogInDocument1.UIPasswordEdit;
#endregion
// Go to web page 'http://localhost:15856/WebSite1/'
uILogInWindowsInternetWindow.NavigateToUrl(new System.Uri(this.RecordedMethodParams.UILogInWindowsInternetWindowUrl));
// Set flag to allow play back to continue if non-essential actions fail. (For example, if a mouse hover action fails.)
Playback.PlaybackSettings.ContinueOnError = true;
// Mouse hover 'Log In' link at (1, 1)
Mouse.Click(uILogInHyperlink);
// Reset flag to ensure that play back stops if there is an error.
Playback.PlaybackSettings.ContinueOnError = false;
// Type 'test' in 'Username:' text box
uIUsernameEdit.Text = this.RecordedMethodParams.UIUsernameEditText;
// The following element is no longer available: IE web control; Process Id [6320], window handle [3168166]
// Type '********' in 'Password:' text box
uIPasswordEdit.Password = this.RecordedMethodParams.UIPasswordEditPassword;
// The following element is no longer available: IE web control; Process Id [6320], window handle [3168166]
}

This is an issue linked to an Internet Explorer patch that was released in September.
KB2870699
This affects VS2010 and VS2012.
Microsoft released a patch that corrects the issue for VS2012 (and I've confirmed that it fixed the issue for me).
http://blogs.msdn.com/b/visualstudioalm/archive/2013/09/17/coded-ui-mtm-issues-on-internet-explorer-with-kb2870699.aspx
Currently the only workaround for VS2010 is to uninstall the patch (KB2870699); however, as with any sort of security patch you'll want to consider carefully whether pulling it is safe to do given your situation.
EDIT: This was not a fun bug for me to deal with. I had just upgraded to VS2012 from VS2010 and all of a sudden I found none of my previously functioning CodedUI tests working. I assumed it was an issue with VS2012 and after banging my head against the wall for the better part of a day I found out it was an issue with a patch. It was just my luck that I upgraded to 2012 at the same time the patch had been installed on my system. Good times!

There is actually an updated for VS 2012 to fix this issue
http://blogs.msdn.com/b/visualstudioalm/archive/2013/09/17/coded-ui-mtm-issues-on-internet-explorer-with-kb2870699.aspx
Hope this helps!

I was having the same problem with my coded ui test. It's an issue with VS-2012 i guess, i tried every update (installing/uninstalling them and everything..) nothing worked.
I tried VS-2013 Ultimate and it worked.

You can use exception handling to capture the error while still not having the test failed.
The test is failing because at the time it performs click action, the control is hidden.
try
{
//your code goes here
}
catch(FailedToPerformActionOnHiddenControlException e)
{
Console.WriteLine(e.Message);
}

Documents.Close makes Word visible

I have been trying a workaround for this, for quite a long time, but haven't found one yet.
On calling Documents.Close(), Word, which was opened with visible = false, becomes visible.
This is my close statement (document is already saved so no need to save again):
WordApp.Documents.Close(Word.WdSaveOptions.wdDoNotSaveChanges,
Word.WdOriginalFormat.wdOriginalDocumentFormat);

You could just call WordApp.Quit().
Office apps still follow the MDI approach: You run 1 App and in that app you can open 1 or more documents.
It's easy to lose track of that App in the background as we usually only open one document. But there are two levels of Close here.

You could also explicitly set WordApp.Visible = false immediately after the operation; this might cause a brief flash, but should set the application back to invisible.
To avoid the brief flash of visibility, sometimes using the WordApp.ScreenUpdating property as well can help. Set it to false before attempting the Documents.Close() call, then reset to true after that's complete.

The accepted solution (calling WordApp.Quit()) was not a viable option for me. I tried setting
WordApp.ScreenUpdating = false
immediately prior to calling Documents.Close() and that did not help either - I still got the screen flash.
I then tried setting
WordApp.ActiveWindow.Visible = false
immediately after opening the document. That did not make any difference either.
Finally I tried setting
WordApp.ActiveWindow.Top = -5000
(so as to move the window display well out of the visible desktop area in my monitor setup - if you have an unusual (giant!) monitor setup that might not work for you, adjust accordingly) and that solved the problem - no more flashing.
An annoying hack, but worked in my case.

None of above comments work for me. I tried with:
WordApp.ActiveWindow.Top = -5000
But my program terminates with "active window is maximized" exception.
I ultimately resolved it by following call before invoke Document.Close():
m_word.ActiveWindow.WindowState = WdWindowState.wdWindowStateMinimize;
It's a perfect solution for me. Hope it would work for you as well.

Using the ActiveDocument.Close() method will not show the window.
WordApp.ActiveDocument.Close(saveChanges: false);

None of the above solutions worked for me.
I finally realized that for me it was the AutoOpen macro that was the problem. Every time a Word document was opened, AutoOpen would make the ActiveDocument.Visible = False, run some changes (like opening the style pane), then turn ActiveDocument.Visible = True at the end.
This final line in AutoOpen is what caused every document to briefly flash on the screen. Removing both ActiveDocument.Visible = False and ActiveDocument.Visible = True from the AutoOpen macro solved the issue.

Disabling WiFi inrastructure access in XP

I've got an app that needs to disable infrastructure access and then re-enable it (please don't ask why. I'm under NDA and it would be hard to explain why without violating that). I'm doing this with p/Invoke in C#.
To disable it, I'm creating the INTF_ENTRY structure, setting the adapter guid, then setting dwCtlFlags to 0 and calling
uint outFlags;
WZCSAPI.INTF_ENTRY intf = new WZCSAPI.INTF_ENTRY();
intf.wszGuid = adapterGuid;
intf.dwCtlFlags = 0;
WZCSetInterface(null, (uint)INTF_FLAGS.INTF_CM_MASK, ref intf, out outFlags)
This works beautifully and does exactly what I expect. My XP settings under "Wireless Network Connection Properties/Wireless Networks/Advanced" switches from "Any available network (access point preferred)" to "Computer-to-computer (ad hoc) networks only". This is exactly what I need it to do...
Before doing this, I retrieve the original settings for the CM_MASK.
So, later on, I try the same thing to restore it (in this case, origCMMask = 2):
uint outFlags;
WZCSAPI.INTF_ENTRY intf = new WZCSAPI.INTF_ENTRY();
intf.wszGuid = adapterGuid;
intf.dwCtlFlags = origCMMask;
WZCSetInterface(null, (uint)INTF_FLAGS.INTF_CM_MASK, ref intf, out outFlags)
But the "Any Available Network" option is not restored in the settings dialog and the HKLM\SOFTWARE\Microsoft\WZCSVC\Parameters\Interface{guid}\ControlFlags concurs that the CM Mask is NOT set back to 2, but is still set to 0 (actual value is 0x07918000, instead of the normal 0x07818002).
Is there some step I'm missing?

You could try with the WlanSetInterface Function, if you have Windows XP with SP3, passing wlan_intf_opcode_bss_type as the OpCode.
Alternatively, you can also try manually with one of the NETSH WLAN command line actions, at least to validate the approach.

disable the wireless card (you can use devcon.exe)
regedit HKLM\SOFTWARE\Microsoft\WZCSVC\Parameters\Interface{guid}\ControlFlags value
enable the wireless card (you can use devcon.exe)