search

ericmckean / chromedriver

Automatically exported from code.google.com/p/chromedriver
0 stars 0 forks source link

sendKeys sends the wrong string to browser (when displaying remotely) #1037

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago 
Issue Description:

I'm having an issue similar to 
https://code.google.com/p/chromedriver/issues/detail?id=435 and 
https://code.google.com/p/chromedriver/issues/detail?id=627.

The "sendKeys()" command is given one string, but the browser ends up seeing 
different characters.  In my case, an "e" seems to get mapped to backspace, so 
"bBeuaeg" comes out as "bug" in the browser.

I'm running chrome and chromedriver on Linux.  The critical thing seems to be 
that chrome is displaying on my OS X display via ssh X11 forwarding and XQuartz 
on the Mac.  If I run the same combination on an "Xvfb" server (so chrome is 
actually displaying on a local Linux X11 server) sendKeys() works fine.

If I diff the chromedriver logs for the two cases, I can see that some 
different keycodes are being sent in the two cases:

@@ -708,11 +665,11 @@
 }
 [x.000][DEBUG]: DEVTOOLS COMMAND Input.dispatchKeyEvent (id=25) {
    "modifiers": 8,
-   "nativeVirtualKeyCode": 66,
+   "nativeVirtualKeyCode": 48,
    "text": "",
    "type": "keyUp",
    "unmodifiedText": "",
-   "windowsVirtualKeyCode": 66
+   "windowsVirtualKeyCode": 48
 }
 [x.000][DEBUG]: DEVTOOLS RESPONSE Input.dispatchKeyEvent (id=25) {

@@ -730,11 +687,11 @@
 }
 [x.000][DEBUG]: DEVTOOLS COMMAND Input.dispatchKeyEvent (id=27) {
    "modifiers": 0,
-   "nativeVirtualKeyCode": 69,
+   "nativeVirtualKeyCode": 8,
    "text": "",
    "type": "rawKeyDown",
    "unmodifiedText": "",
-   "windowsVirtualKeyCode": 69
+   "windowsVirtualKeyCode": 8
 }

Note that the bits of the log that seem to be sending the actual character keys 
(e.g., "b" or "U" ,etc) seem to be identical in the logs.  Its only the "keyUp" 
and "rawKeyDown" events that are different.

If I `egrep -h '(nativeVirtualKey|"text":)'` in the logs I can see the working 
version sent:
   "nativeVirtualKeyCode": 66,
   "text": "",
   "nativeVirtualKeyCode": 0,
   "text": "b",
   "nativeVirtualKeyCode": 66,
   "text": "",
   "nativeVirtualKeyCode": 16,
   "text": "",
   "nativeVirtualKeyCode": 66,
   "text": "",
   "nativeVirtualKeyCode": 0,
   "text": "B",
   "nativeVirtualKeyCode": 66,
   "text": "",
   "nativeVirtualKeyCode": 16,
   "text": "",
   "nativeVirtualKeyCode": 69,
   "text": "",
   "nativeVirtualKeyCode": 0,
   "text": "e",
   "nativeVirtualKeyCode": 69,
   "text": "",
   "nativeVirtualKeyCode": 85,
   "text": "",
   "nativeVirtualKeyCode": 0,
   "text": "u",
   "nativeVirtualKeyCode": 85,
   "text": "",
   "nativeVirtualKeyCode": 65,
   "text": "",
   "nativeVirtualKeyCode": 0,
   "text": "a",
   "nativeVirtualKeyCode": 65,
   "text": "",
   "nativeVirtualKeyCode": 69,
   "text": "",
   "nativeVirtualKeyCode": 0,
   "text": "e",
   "nativeVirtualKeyCode": 69,
   "text": "",
   "nativeVirtualKeyCode": 71,
   "text": "",
   "nativeVirtualKeyCode": 0,
   "text": "g",
   "nativeVirtualKeyCode": 71,
   "text": "",

And doing the same thing on the buggy log shows:
   "nativeVirtualKeyCode": 48,
   "text": "",
   "nativeVirtualKeyCode": 0,
   "text": "b",
   "nativeVirtualKeyCode": 48,
   "text": "",
   "nativeVirtualKeyCode": 16,
   "text": "",
   "nativeVirtualKeyCode": 48,
   "text": "",
   "nativeVirtualKeyCode": 0,
   "text": "B",
   "nativeVirtualKeyCode": 48,
   "text": "",
   "nativeVirtualKeyCode": 16,
   "text": "",
   "nativeVirtualKeyCode": 8,
   "text": "",
   "nativeVirtualKeyCode": 0,
   "text": "e",
   "nativeVirtualKeyCode": 8,
   "text": "",
   "nativeVirtualKeyCode": 68,
   "text": "",
   "nativeVirtualKeyCode": 0,
   "text": "u",
   "nativeVirtualKeyCode": 68,
   "text": "",
   "nativeVirtualKeyCode": 0,
   "text": "",
   "nativeVirtualKeyCode": 0,
   "text": "a",
   "nativeVirtualKeyCode": 0,
   "text": "",
   "nativeVirtualKeyCode": 8,
   "text": "",
   "nativeVirtualKeyCode": 0,
   "text": "e",
   "nativeVirtualKeyCode": 8,
   "text": "",
   "nativeVirtualKeyCode": 52,
   "text": "",
   "nativeVirtualKeyCode": 0,
   "text": "g",
   "nativeVirtualKeyCode": 52,
   "text": "",

I've fetched recent chromedriver, selenium-webdriver and google-chrome:

> ./chromedriver --version
ChromeDriver 2.14.313457 (3d645c400edf2e2c500566c9aa096063e707c9cf)

> grep version node_modules/selenium-webdriver/package.json
  "version": "2.44.0",

> google-chrome --version
Google Chrome 39.0.2171.95

Steps to reproduce (if relevant, you MUST provide a simplified html page or
link to public site):

I've attached a .zip file with a simple test case that sends a string to the 
google.com search bar, and then expects that string to show up correctly in the 
title of the search results page.  (It just prints a message if there was a 
mismatch.)

I've also included my raw and postprocessed chromedriver logs.

-----Other helpful tips:
Attach your chromedriver log with verbose logging enabled (see
http://goo.gl/5Sx8mC for how to do this).

Original issue reported on code.google.com by p...@bebop.co on 13 Feb 2015 at 8:48

Attachments:

GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
you are using Linux chromedriver to drive Mac browser. driver will do remote
, but not cross platform.

Original comment by andrewch...@chromium.org on 17 Feb 2015 at 7:45

GoogleCodeExporter commented 9 years ago 
I am running the Linux chrome browser.  Its displaying (via X11) on the Mac, 
but its the Linux browser.

It looks to me like chromedriver is switching layouts, when it should not be.  
The logs show that chromedriver is sending different keycodes in the two cases 
(local X display vs. remote X display).  If chromedriver was assuming the same 
keyboard layout in both cases, then it would be sending the same keycodes in 
both cases, right?

If there is some way to force a particular keyboard layout, I'm happy to try 
things out.  (I haven't downloaded the chromedriver source yet, but I could do 
that.)

Original comment by p...@bebop.co on 17 Feb 2015 at 8:00

GoogleCodeExporter commented 9 years ago 
The future release of chromedriver  for window will handle this correctly since
it always stick to U.S standard keyboard regardless user's setting.

Original comment by andrewch...@google.com on 18 Feb 2015 at 12:28

GoogleCodeExporter commented 9 years ago

Original comment by samu...@chromium.org on 21 Feb 2015 at 12:18

GoogleCodeExporter commented 9 years ago

Original comment by gmanikp...@chromium.org on 26 Feb 2015 at 12:20

GoogleCodeExporter commented 9 years ago 
We have this same problem. The letters "E" and "e" are mapped through fine, but 
the keyDown and keyUp events either side of it indicate that backspace is hit.

Extract from the chromedriver verbose log:

===

[7.202][DEBUG]: DEVTOOLS RESPONSE Input.dispatchKeyEvent (id=61) {

}
[7.202][DEBUG]: DEVTOOLS COMMAND Input.dispatchKeyEvent (id=62) {
   "modifiers": 0,
   "nativeVirtualKeyCode": 55,
   "text": "",
   "type": "rawKeyDown",
   "unmodifiedText": "",
   "windowsVirtualKeyCode": 55
}
[7.212][DEBUG]: DEVTOOLS RESPONSE Input.dispatchKeyEvent (id=62) {

}
[7.212][DEBUG]: DEVTOOLS COMMAND Input.dispatchKeyEvent (id=63) {
   "modifiers": 0,
   "nativeVirtualKeyCode": 0,
   "text": "c",
   "type": "char",
   "unmodifiedText": "c",
   "windowsVirtualKeyCode": 0
}
[7.214][DEBUG]: DEVTOOLS RESPONSE Input.dispatchKeyEvent (id=63) {

}
[7.214][DEBUG]: DEVTOOLS COMMAND Input.dispatchKeyEvent (id=64) {
   "modifiers": 0,
   "nativeVirtualKeyCode": 55,
   "text": "",
   "type": "keyUp",
   "unmodifiedText": "",
   "windowsVirtualKeyCode": 55
}
[7.215][DEBUG]: DEVTOOLS RESPONSE Input.dispatchKeyEvent (id=64) {

}
[7.215][DEBUG]: DEVTOOLS COMMAND Input.dispatchKeyEvent (id=65) {
   "modifiers": 0,
   "nativeVirtualKeyCode": 8,
   "text": "",
   "type": "rawKeyDown",
   "unmodifiedText": "",
   "windowsVirtualKeyCode": 8
}
[7.220][DEBUG]: DEVTOOLS RESPONSE Input.dispatchKeyEvent (id=65) {

}
[7.220][DEBUG]: DEVTOOLS COMMAND Input.dispatchKeyEvent (id=66) {
   "modifiers": 0,
   "nativeVirtualKeyCode": 0,
   "text": "e",
   "type": "char",
   "unmodifiedText": "e",
   "windowsVirtualKeyCode": 0
}
[7.226][DEBUG]: DEVTOOLS RESPONSE Input.dispatchKeyEvent (id=66) {

}
[7.226][DEBUG]: DEVTOOLS COMMAND Input.dispatchKeyEvent (id=67) {
   "modifiers": 0,
   "nativeVirtualKeyCode": 8,
   "text": "",
   "type": "keyUp",
   "unmodifiedText": "",
   "windowsVirtualKeyCode": 8
}
[7.228][DEBUG]: DEVTOOLS RESPONSE Input.dispatchKeyEvent (id=67) {

}

===

$ google-chrome --version
Google Chrome 41.0.2272.76 

$ chromedriver --version
ChromeDriver 2.14.313457 (3d645c400edf2e2c500566c9aa096063e707c9cf)

$ Xorg -version
X.Org X Server 1.15.1
Release Date: 2014-04-13
X Protocol Version 11, Revision 0
Build Operating System: Linux 3.2.0-76-generic x86_64 Ubuntu
Current Operating System: Linux delitescere-ubuntu 3.13.0-46-generic #75-Ubuntu 
SMP Tue Feb 10 15:24:04 UTC 2015 x86_64
Kernel command line: BOOT_IMAGE=/boot/vmlinuz-3.13.0-46-generic 
root=UUID=0c0cba71-1753-4809-9c88-c998f33123d3 ro console=tty1 console=ttyS0
Build Date: 12 February 2015  02:49:29PM
xorg-server 2:1.15.1-0ubuntu2.7 (For technical support please see 
http://www.ubuntu.com/support) 
Current version of pixman: 0.30.2

And on OS/X:
XQuartz 2.7.7 (xorg-server 1.15.2)

Original comment by j...@canva.com on 6 Mar 2015 at 4:29

GoogleCodeExporter commented 9 years ago 
#7  can you share your test program for  your case?

Original comment by andrewch...@chromium.org on 6 Mar 2015 at 10:54

GoogleCodeExporter commented 9 years ago

Original comment by gmanikp...@chromium.org on 2 Apr 2015 at 7:35