IE LAN Settings changed by WebKing
Question: Can WK be prevented from changing IE settings in pre-existing IE windows?
Versions:
WebKiing ------> 6.05
Java------------->1.4.2_13
OS--------------->XP Pro SP2
IE---------------->7.0.5730.13 and 7.0.5730.13
IE settings------->Automatically Detect Settings
WebKing setting-->Use System Proxy Configuration
Comments
-
First of all, I will explain how WebKing interacts with the proxy settings on Windows machines.
When recording or running functional tests in the browsers, IE sets the proxy settings in those browsers to an internal proxy maintained by WebKing. This gives WebKing additional information that it needs to generate and run tests. If a user already has configured their machine to use their own proxy, then the user should configure WebKing in its proxy preferences to point to that proxy. WebKing will then configure its internal proxy to forward all traffic to the proxy configured in the WebKing preferences. The default proxy host and port used by WebKing is localhost:55555, although port 55556 is also used if 55555 is not available.
Unfortunately, the only way to tell IE what proxy settings to use is to set global registry keys. So right before starting up IE, WebKing sets global proxy registry keys so that the instance of Internet Explorer that it is starting is configured to use WebKing's proxy. Once the new instance of IE starts up, and makes its first connection to the proxy, WebKing resets the registry keys to their initial values. However, even though the registry keys were reset, the new instance of IE continues to use the proxy. In fact, it will continue to use the proxy unless the user goes to the Internet Options panel and turns them off. (Note: Sometimes users do this while a test is running - this is bad and can cause tests to fail.)
Now let's tackle what happens when there is an existing instance of IE running on the machine prior to a user starting and running WebKing. (By the way, this is not a recommended practice, as it can cause the kinds of problems mentioned in this thread, as well as at least one other less obvious problem when testing an application that uses multiple windows.) When WebKing modifies the global registry settings prior to starting its instance of IE, the existing IE instance does not pick up those settings. If a user is to look at the Internet Options panel in the existing IE while a test is running in WebKing, the settings may point at WebKing's proxy. However, it is NOT using those settings UNLESS the user clicks OK in the Internet Options panel. Once the user clicks OK, the proxy settings are updated in the existing IE instance. If the user clicks Cancel, or does not go to the Internet Options panel, then the existing instance of IE never picks up the WebKing proxy settings and should continue to navigate fine. So to reiterate, even though existing instances of IE may look like they are using WebKing's proxy, they are not. The fact that they look like they are probably has to do with the global proxy settings used by Windows and IE. Unfortunately, all of this can be confusing and mostly has to do with how Windows and IE manage proxy settings. If IE allowed us to set proxy settings on a single instance of IE, and didn't require us to modify global registry keys, none of this would be a problem!
As an aside, every now and then WebKing has been known not to reset the proxy settings when it normally does. This can be because IE exited abnormally, there is a hanging IE process, or for other reasons. In those cases this can affect new instances of IE (or other programs that connect to the internet). The user just needs to reset the proxy settings on their machine to what they should be for things to begin working properly again. If there are hanging IE processes (this can be determined by checking Task Manager for more iexplore.exe processes than there are IE windows visible on the machine), the user should kill them. The Parasoft team is working to eliminate all of the cases where the proxy settings don't get reset.
Now that I have explained all this, are there any still unanswered questions that you would like us to address?0 -
Excellent response. It would be great if this info was in the user's guide. The only issue not covered is the case where pre-existing non-WK browsers lose connectivity. This is our main issue, so the next time this happens, I'll ignore the proxy settings but check for hung browser processes. Corporate mandates only IE, even on test boxes.0
-
This is not working on Windows7 with SOAtest 6.2!!First of all, I will explain how WebKing interacts with the proxy settings on Windows machines.
When recording or running functional tests in the browsers, IE sets the proxy settings in those browsers to an internal proxy maintained by WebKing. This gives WebKing additional information that it needs to generate and run tests. If a user already has configured their machine to use their own proxy, then the user should configure WebKing in its proxy preferences to point to that proxy. WebKing will then configure its internal proxy to forward all traffic to the proxy configured in the WebKing preferences. The default proxy host and port used by WebKing is localhost:55555, although port 55556 is also used if 55555 is not available.
Unfortunately, the only way to tell IE what proxy settings to use is to set global registry keys. So right before starting up IE, WebKing sets global proxy registry keys so that the instance of Internet Explorer that it is starting is configured to use WebKing's proxy. Once the new instance of IE starts up, and makes its first connection to the proxy, WebKing resets the registry keys to their initial values. However, even though the registry keys were reset, the new instance of IE continues to use the proxy. In fact, it will continue to use the proxy unless the user goes to the Internet Options panel and turns them off. (Note: Sometimes users do this while a test is running - this is bad and can cause tests to fail.)
Now let's tackle what happens when there is an existing instance of IE running on the machine prior to a user starting and running WebKing. (By the way, this is not a recommended practice, as it can cause the kinds of problems mentioned in this thread, as well as at least one other less obvious problem when testing an application that uses multiple windows.) When WebKing modifies the global registry settings prior to starting its instance of IE, the existing IE instance does not pick up those settings. If a user is to look at the Internet Options panel in the existing IE while a test is running in WebKing, the settings may point at WebKing's proxy. However, it is NOT using those settings UNLESS the user clicks OK in the Internet Options panel. Once the user clicks OK, the proxy settings are updated in the existing IE instance. If the user clicks Cancel, or does not go to the Internet Options panel, then the existing instance of IE never picks up the WebKing proxy settings and should continue to navigate fine. So to reiterate, even though existing instances of IE may look like they are using WebKing's proxy, they are not. The fact that they look like they are probably has to do with the global proxy settings used by Windows and IE. Unfortunately, all of this can be confusing and mostly has to do with how Windows and IE manage proxy settings. If IE allowed us to set proxy settings on a single instance of IE, and didn't require us to modify global registry keys, none of this would be a problem!
As an aside, every now and then WebKing has been known not to reset the proxy settings when it normally does. This can be because IE exited abnormally, there is a hanging IE process, or for other reasons. In those cases this can affect new instances of IE (or other programs that connect to the internet). The user just needs to reset the proxy settings on their machine to what they should be for things to begin working properly again. If there are hanging IE processes (this can be determined by checking Task Manager for more iexplore.exe processes than there are IE windows visible on the machine), the user should kill them. The Parasoft team is working to eliminate all of the cases where the proxy settings don't get reset.
Now that I have explained all this, are there any still unanswered questions that you would like us to address?
its still comming with the localhost on port 55555, all settings are;
SOAtest Preferences General => Webbrowser = Use internal Webbrowser - Firefox
SOAtest Preferences SOAtest => Proxy = Use system proxy configuration
System configuration => Firefox options network = automatic proxyconfiguration with script
System configuration => IE8 LAN settings are settings atomatic detect and automatic script use
System internet options => LAN settings are settings atomatic detect and automatic script use
still SOAtest is comming with de localhost setting and i can't find them back in the settings off SOAtest....
anyone a solution??
0