Skip to content
This repository has been archived by the owner on Nov 29, 2018. It is now read-only.

IE x64 slow typing #5116

Open
lukeis opened this issue Mar 4, 2016 · 51 comments
Open

IE x64 slow typing #5116

lukeis opened this issue Mar 4, 2016 · 51 comments

Comments

@lukeis
Copy link
Member

lukeis commented Mar 4, 2016

Originally reported on Google Code with ID 5116

IE10 is very very slow typing (about 1 char every 4-5 seconds), and will throw a Selenium
error if you pass text that is too long.

This affects any textbox or textfield.

Selenium version: 2.28
OS: Win8
Browser: IE10

Reported by kevin.t.dillon on 2013-02-01 15:55:07

@lukeis
Copy link
Member Author

lukeis commented Mar 4, 2016

Reported by barancev on 2013-02-02 19:56:12

  • Labels added: Browser-IE

@lukeis
Copy link
Member Author

lukeis commented Mar 4, 2016

Reported by barancev on 2013-02-02 19:56:24

  • Labels added: Performance

@lukeis
Copy link
Member Author

lukeis commented Mar 4, 2016

For the record: regression tests in IE10 are almost as fast as in previous versions,
see [1]

[1] http://ci.seleniumhq.org:8080/view/IE%20Tests/

Reported by barancev on 2013-02-03 20:51:40

@lukeis
Copy link
Member Author

lukeis commented Mar 4, 2016

Reported by barancev on 2013-02-10 18:25:25

@lukeis
Copy link
Member Author

lukeis commented Mar 4, 2016

This is happening for me on Windows 2012 + IE10 x64 + Selenium 2.31 + IEDriver x64 2.31

Reported by jahmai@criticalarc.com on 2013-03-03 11:57:55

@lukeis
Copy link
Member Author

lukeis commented Mar 4, 2016

Issue 5254 has been merged into this issue.

Reported by james.h.evans.jr on 2013-03-04 15:46:01

@lukeis
Copy link
Member Author

lukeis commented Mar 4, 2016

I also experience slow typing in with selenium 2.31 Downgrading to 2.30 solved the issue
for me.
Win 7 x64 - Firefox 19 

Reported by synthesis7 on 2013-03-18 10:17:39

@lukeis
Copy link
Member Author

lukeis commented Mar 4, 2016

Also happening on Windows 8 + IE10 + Selenium 2.31 + IEDriver x64 2.31

Reported by jonsibonsi on 2013-03-20 02:00:47

@lukeis
Copy link
Member Author

lukeis commented Mar 4, 2016

We had the same problem in IE 10 64 bit and Win 7
Using the 32 bit driver (and thus IE 10 32) 'solved' the issue here

Reported by raijtje on 2013-03-22 13:45:03

@lukeis
Copy link
Member Author

lukeis commented Mar 4, 2016

I can confirm this.  I just upgraded to IE10 from IE9 using 64bit driver originally.
(using windows 7)  After upgrading to IE10, the performance of sendkeys slowed down
to around 2-4 seconds between keystrokes.

After switching out the drivers for the 32 bit version, speed returned to normal.

Reported by SBSquid on 2013-03-25 18:28:19

@lukeis
Copy link
Member Author

lukeis commented Mar 4, 2016

Thank u i am using 32 bit now 

Reported by anandseshadri07 on 2013-03-27 09:19:21

@lukeis
Copy link
Member Author

lukeis commented Mar 4, 2016

still experiencing it, windows 7 64bit, IE 10, selenium 2.33.0

Reported by wangjsh on 2013-07-19 18:01:41

@lukeis
Copy link
Member Author

lukeis commented Mar 4, 2016

I am also experiencing this on Win 7 + IE10 64 bit + Selenium 2.34.0 + IE Driver x64
2.35.2.
Text input speed is very fast with Firefox, Chrome and IE10 32 bit. 

Reported by hphilliph on 2013-08-20 22:34:00

@lukeis
Copy link
Member Author

lukeis commented Mar 4, 2016

Just wanted to report that i tested on Windows Server 2008 with IE 11 64 bit + Selenium
2.37 - Issue still occurs. (But using the 32 bit IE driver server is still a viable
workaround...) Any idea when this problem might be fixed?

Reported by arthur.blake on 2013-12-02 18:54:46

@lukeis
Copy link
Member Author

lukeis commented Mar 4, 2016

It'll be fixed when Microsoft fixes the SendMessage API in x64, and not until. Or unless
someone can debug why the SendMessage call for keystrokes is so slow in 64-bit Windows.
As of now, there's nothing in the IE driver C++ code to indicate where the issue might
be.

Reported by james.h.evans.jr on 2013-12-02 19:19:42

  • Labels removed: Status-Untriaged

@lukeis
Copy link
Member Author

lukeis commented Mar 4, 2016

Issue 6694 has been merged into this issue.

Reported by james.h.evans.jr on 2013-12-09 13:00:48

@lukeis
Copy link
Member Author

lukeis commented Mar 4, 2016

OK, thanks for the update. With this problem, the 64 bit version is pretty much useless.
You might want to put a big warning on the download page at http://docs.seleniumhq.org/download/
mentioning this. All that's really there is "(recommended)" preceding the 32 bit driver.
It's not clear at all that 64 bit version is useless!

Reported by arthur.blake on 2013-12-09 19:52:40

@lukeis
Copy link
Member Author

lukeis commented Mar 4, 2016

Issue 6844 has been merged into this issue.

Reported by james.h.evans.jr on 2014-01-15 08:19:52

@lukeis
Copy link
Member Author

lukeis commented Mar 4, 2016

this issue has gone away for me

Reported by kevin.t.dillon on 2014-01-27 15:49:23

@lukeis
Copy link
Member Author

lukeis commented Mar 4, 2016

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.

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

  • Status changed: Accepted

@lukeis
Copy link
Member Author

lukeis commented Mar 4, 2016

I would suggest not even building or publishing the 64 bit version... what's the point?
Almost any selenium program out there will be using keystrokes and the 64 bit version
is not usable. There is still not a big fat warning at the main download page at http://docs.seleniumhq.org/download/
so newbies will continuously get caught by this gotcha, over and over.

Reported by arthur.blake on 2014-01-31 20:24:40

@lukeis
Copy link
Member Author

lukeis commented Mar 4, 2016

Not publishing the 64-bit version of the server is not an option, because IE8 (the browser
version for Windows 7 RTM) and IE9 can both be run as a 64-bit application, and people
may explicitly want to automate that. It should be noted that the 64-bit IEDriverServer
executable works fine against 64-bit versions of IE < 10.

Also, the 64-bit version of IEDriverServer.exe is the only way to generate full-page
(non-truncated) screenshots for IE >= 10 on a 64-bit operating system. See issue #5876
for the full story, but it's the root cause as this, but in reverse.

Finally, if you're unhappy with the way the documentation pages at seleniumhq.org look,
patches and/or pull requests are welcome[1].

[1] https://github.com/SeleniumHQ/www.seleniumhq.org

Reported by james.h.evans.jr on 2014-01-31 20:55:36

@lukeis
Copy link
Member Author

lukeis commented Mar 4, 2016

I used 32 bit driver and it worked for me.

Reported by dmukesh83 on 2014-05-14 22:50:47

@lukeis
Copy link
Member Author

lukeis commented Mar 4, 2016

I experience the same issue on settings below.

OS : Windows 7 64bit
Browser : Internet Explorer 11
Selenium 2.42.2
IEDriverServer 2.42.0

Reported by crockabiscuit on 2014-09-16 01:35:03

@lukeis
Copy link
Member Author

lukeis commented Mar 4, 2016


I had same issue with 64 bit driver on Windows 7 and IE 11. Now, works with 32 bit
driver


Regards

Reported by benjamin.garcia@geomatys.com on 2014-09-30 16:03:39

@lukeis
Copy link
Member Author

lukeis commented Mar 4, 2016

Me too!

IE11
Windows 7 SP1 x64
IEDriverServer.exe v2.43.0 (x64)
Java 1.7 u67 x64
selenium-java 2.43.1

Reported by PredatorVI on 2014-10-09 18:44:23

@lukeis
Copy link
Member Author

lukeis commented Mar 4, 2016

Please see http://jimevansmusic.blogspot.com/2014/09/screenshots-sendkeys-and-sixty-four.html
for a full, technical explanation of the hurdles involved with fixing this issue.

Reported by james.h.evans.jr on 2014-10-09 18:46:12

@lukeis
Copy link
Member Author

lukeis commented Mar 4, 2016

Issue 8087 has been merged into this issue.

Reported by james.h.evans.jr on 2014-10-25 00:54:05

@lukeis
Copy link
Member Author

lukeis commented Mar 4, 2016

Reported by barancev on 2014-11-05 18:39:44

@lukeis
Copy link
Member Author

lukeis commented Mar 4, 2016

Me too

Me too!

IE11
Windows 7 SP1 x64
IEDriverServer.exe v2.44.0 (x64)
Java 1.8.0_05 x64
selenium-java 2.44.0

Reported by my.selenium.name on 2014-11-11 12:54:44

@lukeis
Copy link
Member Author

lukeis commented Mar 4, 2016

Use 32-bit IEDriverServer.exe.  FWIW, the 32-bit version seems to be working fine on
IE8/IE9 as well for me, though I've just barely started validating our web application
using those versions of IE and have hit other issues that have stalled my testing.

Reported by PredatorVI on 2014-11-11 16:11:09

@lukeis
Copy link
Member Author

lukeis commented Mar 4, 2016

32-bit IEDriverServer.exe [2.44] on IE 11 [32 bit] on Win 7 [64 bit] also showing this
slowness

Reported by sunalps2000 on 2014-11-25 08:12:25

@lukeis
Copy link
Member Author

lukeis commented Mar 4, 2016

Guys, how did you manage to install IE11 x86 on Windows7-64? 32bit IEDriverServer does
not work in my 64bit environment. 

org.openqa.selenium.WebDriverException: Error forwarding the new session Error forwarding
the request Read timed out

Reported by evgeny.mukhin on 2014-12-29 07:47:52

@lukeis
Copy link
Member Author

lukeis commented Mar 4, 2016

Same issue as #3072

Reported by markkondor on 2015-02-27 11:36:43

@lukeis
Copy link
Member Author

lukeis commented Mar 4, 2016

I have the same issue. I'm using Win8.1 IE11 - IEDriver 2.44 both 32 and 64bit are typing
slow to me - it's crashing my tests.

Reported by toytesterf2014 on 2015-03-05 20:41:09

@lukeis
Copy link
Member Author

lukeis commented Mar 4, 2016

I was having the same issue using IE11 with the 32 bit IEDriver 2.45. Based on the majority
of this thread, using the 32 bit driver was supposed to resolve the slow typing issue.
However, I tried switching to the 64 bit driver, and it works now! Super fast typing
and seems like the cases run faster overall.

Reported by gallowdp on 2015-03-11 16:59:54

@lukeis
Copy link
Member Author

lukeis commented Mar 4, 2016

IEDriverServer_x64_2.45.0
IE Version: 11.0.9600.17690
Windows 8.1 Pro 64-bit
(capybara) "fill-in" input is painfully slow
  fill_in 'user_id', with: username
  fill_in 'password', with: password

Reported by qtrolazyg on 2015-03-20 15:33:45

@lukeis
Copy link
Member Author

lukeis commented Mar 4, 2016

I too came across the same issue for the following config.

wind8
ie11
64 bit iedriver.

Now got resolved by change the IEdriver 32 from 64.

Thanks Guys...!!

Reported by rgrthiru on 2015-04-20 11:30:08

@lukeis
Copy link
Member Author

lukeis commented Mar 4, 2016

Just trying to get a sense of closure and next steps here, after I read through this
entire thread, I am totally lost, since there are conflicting reports between which
works better


For me, I have the exact experience as comment #40. With IE11:

32-bit 2.45.0 with selenium 2.45.0 : 
------------------------------------
    Is slow as originally reported. Native events off is fast, but breaks all non-text
key based testing (like ctrl, shift etc). So I can't use this without breaking a set
of my tests.



64-bit 2.46.0: 
---------------
    Is much faster! So I am having the reverse experience of most people in this list.


What's up? I am going to go ahead and give 64-bit a try. I wonder how this is going
to do with Ie9 and 10 which I still have to support.

Reported by binod80 on 2015-06-15 18:40:36

@lukeis
Copy link
Member Author

lukeis commented Mar 4, 2016

The root cause of slow keystrokes is well-understood. It has been documented both here
(in comment #21), and in further detail in a blog post (referred to here in comment
#31). The issue is caused when you have a mixed-mode of 64-bit and 32-bit processes
in IE. This is the norm on 64-bit Windows, running IE 10 or IE 11.

There *are* circumstances for those browser versions on 64-bit Windows where you can
end up with a 64-bit "manager" process *and* a 64-bit "content" process, and those
circumstances are explained in Eric Lawrence's blog post on IE internals (linked to
in the aforementioned blog post from comment #31, and available at http://blogs.msdn.com/b/ieinternals/archive/2012/03/23/understanding-ie10-enhanced-protected-mode-network-security-addons-cookies-metro-desktop.aspx).
If you find yourself in one of those circumstances, then the 64-bit driver will indeed
work with the performance you would see in IE 9 and below.

I personally have not seen the behavior you describe where the 64-bit driver yields
fast keystrokes in IE 10 or 11. That's an extraordinary claim. No one to date has supplied
the extraordinary evidence (in the form of IEDriverServer log files indicating that
the Windows hook procedures were properly set) to support that claim.

Reported by james.h.evans.jr on 2015-06-15 20:33:18

@lukeis
Copy link
Member Author

lukeis commented Mar 4, 2016

Thanks Jim. I have to investigate further, but so far one interesting bit of info I
found is that my IE has this checked on, and this setting is referred to in the doc
you linked to, does this ring any bells or explain why I am getting IE + 64 bit typing
working fast?


-Enable Enhanced Protected Mode = ON

I will try some other other things like turning it off.

Reported by binod80 on 2015-06-16 14:34:32

@lukeis
Copy link
Member Author

lukeis commented Mar 4, 2016

Jim, I have verified that

with 64-bit IEDriver


turning the Enhanced Protected mode = ON means fast typing (and indeed both processes
are 64-bit)

Turning Enhanced Protected mode = OFF means slow typing (and the nested iexplore.exe
is 32 bit in this case)

I think I can go with this setting and the 64 bit driver.

You rock!

Reported by binod80 on 2015-06-16 18:20:29

@lukeis
Copy link
Member Author

lukeis commented Mar 4, 2016

That seems to be in line with what Eric Lawrence has written. Note, however, that with
Enhanced Protected Mode on, you may experience other issues with the driver, including
being unable to find elements, the driver losing connection to the browser, or other
potential unknown issues. It's an untested state, and it's unlikely to be tested thoroughly
anytime soon, due to the impending release of Microsoft Edge. If you're willing to
take the risk, fine, but be aware that any issues you may report will immediately be
invalidated until reproduced with Enhanced Protected Mode off.

Reported by james.h.evans.jr on 2015-06-16 18:24:27

@lukeis
Copy link
Member Author

lukeis commented Mar 4, 2016

Ok, so logically then I should use 32 bit and turn that setting off to get fast typing
plus stability. I started pursuing that.

I now have full confirmation that the slowness is perfectly reproducible when the content
iexplore.exe is 64 bit, and perfectly not reproducible when it is 32 bit. Using a 32
bit driver. So that makes sense based on what you explained.

What I don't have yet is the ability to control the bitness. On one machine, simply
switching the Enhanced Protected Mode to Off does the trick. All I have to do to verify
is start IE again and I can see it switch between 32 bit and 64 bit as I change this
setting, and that lines up with typing speed too. This is Machine 1.


What I don't know then is why I can't use that same setting to get the iexplore to
switch between 32 and 64 bit, on a different machine with IE11. This is Machine 2.

I don't even know where to start, since there could be so many differences between
the IE settings on the two hosts.

Machine 1 : Where the EPM control typing completely

   windows 7
   latest update KB3061518
   IE11 update version 11.0.19

Machine 2 : Where the EPM seems to be making no difference. This is the mystery case
I need to solve (and in fact these are the test machines in our labs so...)

The settings listed appear to be the same as Machine 1.
   windows 7
   latest update KB3061518
   IE11 update version 11.0.19



Reading the article it only talks about IE9,10. But not about IE11 since it probably
predated it? Perhaps there is another switch here?


I need to solve this last puzzle since doing so means I can turn off EPM and go happily
about testing with 32 bit driver.

Appreciate help in advance

Reported by binod80 on 2015-06-17 14:51:08

@lukeis
Copy link
Member Author

lukeis commented Mar 4, 2016

For windows8 64 bit m/c 
======================
Issue is not with IE updates (eg 7,8,9,10 or 11)  but with 64 bit version of IE .with
32 bit version you wont face any issue .
"Program files X86" will contain 32 bit version of IE
"Program files" will contain 64 bit version of IE 

In eclipse while downloading "InternetExplorerDriver " from seleniumhq.org , download
32 bit variant and everything would work fine  

Reported by bipin.thakare on 2015-07-23 11:10:56

@lukeis
Copy link
Member Author

lukeis commented Mar 4, 2016

Was there any fix for the issue? - Any work around to use 64-bit IE Server?

Reported by kiran.yajjala on 2015-09-08 10:56:52

@lukeis
Copy link
Member Author

lukeis commented Mar 4, 2016

Please let me also know if there is any fix except using the ugly doc.getElem..().setValue...
methods.


Reported by anandbansal5 on 2015-09-15 14:22:08

@lukeis
Copy link
Member Author

lukeis commented Mar 4, 2016

Reported by luke.semerau on 2015-09-17 17:45:11

  • Labels added: Restrict-AddIssueComment-Commit

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

1 participant