Recently I’ve been trying to adapt Selenium 1 test cases designed to work in Firefox on Linux to Internet Explorer on Windows Vista. I installed the non-Grid version of Selenium on the Windows Vista box in order to test it, and found that while the “*iexplore” and “*iehta” launchers failed to work. “*iehta” and “*iexplore” both seem to enter an infinite loop when their .start() commands are run, with the .start() function never returning. Both also open up an Internet Explorer window leading to a location on the localhost’s computer in C:/Users/($the current user’s account)/AppData/Local/Temp that appears to be a blank page corresponding to an IE profile of some sort.
“*iexploreproxy” worked just fine on a standalone selenium server and remote control both run on the same machine. However, when trying to connect to the continuous-integration Linux hub on Selenium Grid, “*iexploreproxy” no longer worked. When run on Selenium Grid, “*iexplore” opens (and then immediately closes) an IE window, presumably the Selenium remote control. “*iehta” opens a Selenium remote control, but never returns the session ID to the hub, allowing the hub to start transmitting Selenese commands, causing the same behavior that was experienced on the standalone Selenium server.
However, if “*iehta” is manually halted (like by opening a python terminal on the same machine as the hub, requesting an instance of Selenium running “*iehta” called “sel” from the hub, running sel.start(), then hitting control-C during the resulting infinite loop, if another remote control for the grid has “*iexploreproxy” available, the hub can then run instances of Selenium on “*iexploreproxy” that are usable for testing purposes. Some strange discrepancies I’ve noticed are that on “*iexploreproxy”, multiple consecutive instances of Selenium appear to share cookies and Basic HTTP Authentication login data between them (on Firefox I need to retype these passwords with each running of Selenium), and attempts to access domains outside the one “*iehta” was originally assigned to fail (IE, if I requested that “*iehta” start a browser in http://development.place.com, attempting to start another browser in http://stagingarea.place.com would result in Selenium failing.) Similarly, Internet Explorer windows are not closed when selenium.stop() is run, whereas all Firefox windows close under that circumstance. As near as I can tell, *iehta is creating an Internet Explorer profile that *iexploreproxy then uses.
Does anyone who is more familiar with Selenium on IE than me, or has knowledge about the inner workings of *iehta, know how to consolidate the *iehta call and the *iexploreproxy call so this fragile workaround does not have to be employed? The fact that I don’t fully understand it means that all my tests have to be run manually, something I’d rather avoid so I can get back to working on new features.
Start your command prompt in admin mode and then run the selenium jar in that command prompt. That should fix the issue.