I'm using selenium and python on windows7.
My code:
import os
from selenium import webdriver
# get the path of IEDriverServer
#dir = os.path.dirname(__file__)
#ie_driver_path = dir + "\IEDriverServer.exe"
ie_driver_path = "C:\Python36\Scripts\IEDriverServer.exe"
# create a new Internet Explorer session
driver = webdriver.Ie(ie_driver_path)
driver.implicitly_wait(30)
driver.maximize_window()
# create a new Firefox session
#driver = webdriver.Firefox()
#driver.implicitly_wait(30)
#driver.maximize_window()
# navigate to the application home page
driver.get("http://demo-store.seleniumacademy.com/")
# get the search textbox
search_field = driver.find_element_by_name("q")
search_field.clear()
# enter search keyword and submit
search_field.send_keys("phones")
search_field.submit()
...
The code works but when opens Ie the digitation of "phones" is very slow (about 20 seconds). In firefox instead is almost instantaneous.
Why so? It is normal? I'm doing something wrong?
PS: also, where is it better to put my IEDriverServer.exe? Inside C:\Python36\Scripts so I have just one file for all my projects or inside each projects (like in the part commented out)?
Yes, you observed it right.
Using 64-bit IEDriverServer.exe send_keys() populates the field with the character sequence very slowly.
@JimEvans in the article Screenshots, SendKeys, and Sixty-Four Bits mentions that ...there are a couple of issues with the Internet Explorer driver that have been around since IE10 was released....
Comments in the discussion IE x64 slow typing mentions that any fix would require "a massive rearchitecture of the IE driver's binary components, [so] no timeline is (or will be) available" for the delivery of a fix. What causes these issues? How are they related? Why would a fix be so darned difficult? The answers to those questions can all be summed up with a simple answer: "Windows Hooks."
When you are running IE 10 or higher on a 64-bit version of Windows, by default the process which hosts the containing window that includes the browser chrome (address bar, navigation buttons, menus, etc.) is a 64-bit process. The process which hosts the window where content is actually rendered (within each tab) is a 32-bit process.
By default, the IE driver attempts to use a windows hook on the content-rendering window to make sure that a key-down message is properly processed before sending a key-up message. This is where the problem is. The windows hook is not installed, because a 32-bit process (the content-rendering process) can't execute 64-bit code. The only way to properly fix this will be to create a second (32-bit) executable to perform the wait for the key-down to be complete. Since this would amount to a massive rearchitecture of the IE driver's binary components, no timeline is (or will be) available for this change. This means that even when you are running 64-bit Windows, you're likely using a 32-bit version of IE to render the content. This is a powerful argument for continuing to use the 32-bit version of the IE driver for IE 10 and above: you're not actually running against a 64-bit version of IE.
If you insist that you must run the 64-bit version of IEDriverServer.exe, you have two possible workarounds. First, you can disable native events by setting the "nativeEvents" capability to false using whatever mechanism your language binding provides for this. A more accurate workaround from an input simulation perspective would be to enable the "requireWindowFocus" capability, though this also has a windows hook dependency, which may manifest in other ways.
All Windows applications have a routine in them called a "message loop." The message loop repeatedly calls the GetMessage API function, and processes messages sent to the application as they arrive in its queue. Hooks are a feature of the Windows message handling system that allow a developer to intercept, examine, and modify the message being sent to the application. By installing a hook, a developer could, for example, validate that a certain message was processed by the window being hooked. Or they could modify a message sent to the window to represent that the operating system could do things it actually can't. It's a clever mechanism, but it does have a few requirements which is out of scope for this discussion.
Instead of 64-bit IEDriverServer executable try to use 32-bit IEDriverServer executable
You can put the IEDriverServer.exe anywhere within your system and pass the absolute location of the binary through the argument executable_path as follows (Windows OS example):
from selenium import webdriver
driver = webdriver.Ie(executable_path=r'C:\path\to\IEDriverServer.exe')
driver.get("https://www.facebook.com/")
print("Page Title is : %s" %driver.title)
driver.quit()