0

In my c# code, I'm working with Selenium version 3.4. When working with the Chrome browser, the FindElemnt seems to be executed fast compared to IE11. Seems that the FindElemnt method faces some slowness when working with IE11.

Any suggestions??

Nadeem Bader
  • 163
  • 2
  • 9
  • Questions seeking debugging help ("**why isn't this code working?**") must include the desired behavior, a *specific problem or error and the shortest code necessary* to reproduce it **in the question itself**. Questions without a **clear problem statement** are not useful to other readers. See: [mcve]. – JeffC Jul 28 '19 at 01:58

1 Answers1

0

Ensure you are not using the 64-bit version of the IE WebDriver. It appears to be a known issue. Based on this question there may be some ways to speed up the 64-bit version but I personally have found the 32-bit version to be more reliable.

Info on the underlying issue can also be found in this thread

After investigation of this issue, I have been able to debug the C++ code of the 64-bit IE driver to determine the root cause. 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.

Some notes. Careful readers will have already realized that 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.

by james.h.evans.jr on 2014-01-31 19:23:06

Even using the 32-bit version, the IE driver is still significantly slower running the same tests as a Chromium based browser. I have had to add Waits due to the longer page load times using the IE Driver.

J.D. Cain
  • 639
  • 4
  • 16