Issue Description:
Using a canary build of chrome w/ the headless flag, sendkeys doesn't work if driving with chromedriver. It'd be super nice to have a solution for this because otherwise the headless flag is wayyy less useful.
Steps to reproduce:
I'm using docker for this, so bear with me.
Throw all of this into a terminal:
1) docker run --entrypoint=bash -it justinribeiro/chrome-headless:latest
Inside the docker container from here on out
2) apt-get update && apt-get install wget unzip python python-pip
3) LATEST=$(wget -q -O -)
4) wget
5) unzip chromedriver_linux64.zip && ln -s $PWD/chromedriver /usr/local/bin/chromedriver
6) echo '#\!/usr/bin/env bash' > /usr/bin/google-chrome
7) echo '/opt/stickmanventures/chrome-headless/headless_shell --headless --no-sandbox "$@"' >> /usr/bin/google-chrome
8) chmod 755 /usr/bin/google-chrome
9) pip install selenium
10) python
11) follow the python steps found here:
Here's the output of the python steps:
root@9c6a5969d51b:/# python
Python 2.7.12 (default, Nov 19 2016, 06:48:10)
[GCC 5.4.0 20160609] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import time
>>> from selenium import webdriver
>>>
>>> driver = webdriver.Chrome()
>>> driver.get('');
>>> search_box = driver.find_element_by_name('q')
>>> search_box.send_keys('ChromeDriver')
Traceback (most recent call last):
File "<stdin>", line 1, in <module> 249, in execute
self.error_handler.check_response(response)
File "/usr/local/lib/python2.7/dist-packages/selenium/webdriver/remote/errorhandler.py", line 193, in check_response
raise exception_class(message, screen, stacktrace)
selenium.common.exceptions.WebDriverException: Message: unknown error: an X display is required for keycode conversions, consider using Xvfb
(Session info: content shell=)
(Driver info: chromedriver=2.29.461571 (8a88bbe0775e2a23afda0ceaf2ef7ee74e822cc5),platform=Linux 4.9.4-moby x86_64)
Chrome Canary builds are not available for Linux platform. Did you test on Chrome Dev build? What is the version of chrome browser ?
Sorry, it was someone else's early build of the headless project that didn't have the version flag. Just realized that the google-chrome-unstable has the headless flag these days, so I used that.
root@aa791cabef8b:/# google-chrome --version
Google Chrome 59.0.3071.9 dev
To install in that container, you essentially need to take the steps I outlined above and skip steps 6-8, but instead do...
6) sh -c 'echo "deb [arch=amd64] stable main" >> /etc/apt/sources.list.d/google.list'
7) apt-get install apt-transport-https && apt-get update && apt-get install google-chrome-unstable
I think this should work, but haven't tested it yet from the start of those instructions.
And then when you start the chromedriver in python, you'll need to add in a set of options for the headless chrome:
>>> from selenium.webdriver.chrome.options import Options
>>>
>>> chrome_options = Options()
>>> chrome_options.add_argument("--disable-gpu")
>>> chrome_options.add_argument("--no-sandbox")
>>> chrome_options.add_argument("--headless")
>>> driver = webdriver.Chrome(chrome_options=chrome_options)
It still gives the same error though.
I tried the test without docker setup in following manner :-
from selenium import webdriver
from selenium.webdriver.chrome.options import Options
opts = Options()
opts.add_argument('--headless')
opts.add_argument('--no-sandbox')
opts.add_argument('--disable-gpu')
opts.binary_location = "/usr/bin/google-chrome-unstable"
browser = webdriver.Chrome(chrome_options=opts, executable_path='/path/to/chromedriver')
browser.get('')
elem = browser.find_element_by_name('q')
elem.send_keys('testing')
browser.quit()
and it works fine with Chromedriver v2.29 on Chrome v59.0.3071.9 dev.
Do you know if this happens only with docker setup? Can you also please provide chromedriver verbose logs?
Were you in a "headless environment"? If I add XVFB (or I imagine, if I run on mac/windows/another GUI environment), it does work. I guess I'm not sure where this should land, on the Chromedriver side, or the headless chrome side. I'll get you the verbose logs tomorrow. Our hope was that we wouldn't have to have the overhead of XVFB if chrome doesn't need to render anything. I know with just the chrome debugging protocol, we can do sendkey actions in a headless environment, so it just seemed like it should be possible for chromedriver.
(see:, which is running headless chrome in docker using the debugging protocol and is able to send keys)
#4 I am running into the same problems you are.
Booted up a minimal CentOS7 environment and just ran into this issue when trying to use sendKeys() (Java/Selenium). I'm using ChromeDriver v2.29.
I did see some material on re: Chrome's usage of WebKit Events vs "Raw Events". I assume this may help me towards using sendKeys(), but there is no information on how to toggle the usage of WebKit events.
Is the current workaround to just run an instance of Xvfb? Echoing #4, I had hoped that we wouldn't have to use Xvfb.
Ran into this with the following versions:
OS: Ubuntu 14.04
Chromium 60.0.3097.0
Chromedriver: 2.29.464589 (7cda776b17ae612ddc45b948e4a350a5295a1b5b)
Using ""selenium-webdriver" gem with Ruby. I have attached the script. The error comes only at "element.send_keys" call.
Full error message:
Selenium::WebDriver::Error::UnknownError: unknown error: an X display is required for keycode conversions, consider using Xvfb
(Session info: headless chrome=60.0.3097.0)
(Driver info: chromedriver=2.29.464589 (7cda776b17ae612ddc45b948e4a350a5295a1b5b),platform=Linux 4.4.0-64-generic x86_64)
from /home/deploy/.rbenv/versions/2.2.3/lib/ruby/gems/2.2.0/gems/selenium-webdriver-3.4.0/lib/selenium/webdriver/remote/response.rb:69:in `assert_ok'
Looks like we should maybe switch from keycode_text_conversion_x.cc to keycode_text_conversion_ozone.cc in headless mode?
+johnchen@
John is the new lead for Chromedriver.
I have the same issue Ubuntu 16.04.2
Google Chrome: 59.0.3071.47 beta
Chrome Driver: 2.29.461571
Selenium: 3.4.1
>>> from selenium import webdriver
>>> from selenium.webdriver.chrome.options import Options
>>> opts = Options()
>>> opts.add_argument('--headless')
>>> opts.add_argument('--no-sandbox')
>>> opts.add_argument('--disable-gpu')
>>> browser = webdriver.Chrome(chrome_options=opts, executable_path='/usr/local/bin/chromedriver')
>>> browser.get('')
>>> browser.title
'Google'
>>> browser.find_element_by_name('q').send_keys('test')
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/home/user/.local/lib/python3.5/site-packages/selenium/webdriver/remote/webelement.py", line 349, in send_keys
'value': keys_to_typing(value)})
File "/home/user/.local/lib/python3.5/site-packages/selenium/webdriver/remote/webelement.py", line 493, in _execute
return self._parent.execute(command, params)
File "/home/user/.local/lib/python3.5/site-packages/selenium/webdriver/remote/webdriver.py", line 252, in execute
self.error_handler.check_response(response)
File "/home/user/.local/lib/python3.5/site-packages/selenium/webdriver/remote/errorhandler.py", line 194, in check_response
raise exception_class(message, screen, stacktrace)
selenium.common.exceptions.WebDriverException: Message: unknown error: an X display is required for keycode conversions, consider using Xvfb
(Session info: headless chrome=59.0.3071.47)
(Driver info: chromedriver=2.29.461571 (8a88bbe0775e2a23afda0ceaf2ef7ee74e822cc5),platform=Linux 4.4.0-75-generic x86_64)
irisu@, this was also mentioned in the comments of
Have you been able to repro this?
I have been able to reproduce the error.
I am able to avoid the error if I compile chrome and chromedriver with the use_ozone = true build flag. Unfortunately the choice between keycode_text_conversion_x.cc vs keycode_text_conversion_ozone.cc is made at compile time, whereas the choice to run chrome in headless mode is done at runtime.
I will have to look into this more to find a good solution.
Has there been any progress with this?
I can confirm this is happening too on Ubuntu Server headless with Chromedriver 2.29 and Chrome 59. This is a dealbreaker for using Chrome headless right now :(
> Is the current workaround to just run an instance of Xvfb? Echoing #4, I had hoped that we wouldn't have to use Xvfb.
Actually I have seen workarounds where people were using JavaScript to fill the form fields instead of using `sendKey`. If you're looking for an immediate fix to get rid of Xvfb that's probably your best shot.
I was able to re-compile chrome and chromedriver with use_ozone = true
This eliminated the send_keys errors, but at this point I'm still unclear if the timeout errors are my site or my build :)
Same issue when using chromedriver 2.30.
Like previously stated, I was hoping I could use headless without Xvfb.
After all, its stated in the FAQ of this blogpost that Xvfb will not be required at all.
This blocking the use of headless chrome for me
Current implementation of chromedriver requires an X display to translate text into keystrokes on Linux, thus the requirement for Xvfb when a real X display isn't available.
irisu@chromium.org: you're currently the owner of this bug. Could you please give an update on the progress of finding a fix? Thanks.
Any updates on this topic?
I've confirmed that use_ozone compile-time option does work for ruby / capybara and the send_keys error.
It's a solid workaround for now.
can you please advice command line which will rebuild chrome for ubuntu 16
The upstream build instructions are documented [1]. The instructions were written for Ubuntu, so it should be relatively straightforward.
[1]
Hi.
Any update on that issue ? It makes all that effort put into headless version useless :/
Have a nice day.
I agree, it makes the headless version useless... It's a little alarming that the issue owner hasn't checked on this issue for 15 days or so
Owner: █ irisu@chromium.org
Last visit 15 days ago
Hi,
For Heroku CI[1] we are hoping to only support Headless Chrome, rather than with Xvfb. Once this issue has been addressed I believe we can retire the Xvfb hacks that we have.
Thanks,
Guðmundur Bjarni
[1]:
Hi,
When can we expect an update on this issue?
Using Xvfb hacks makes headless chrome useless. Using javascript hacks to "send keys" defeats the purpose of using chromedriver in the first place. Disappointed that headless chrome is still not viable.
The following revision refers to this bug:
commit 9b0c6e7bfb63034c8cd9784f5f18a83a92a95ca1
Author: jzfeng <jzfeng@chromium.org>
Date: Sat Jun 24 00:14:29 2017
use ozone implementation for key code conversion when there is no X display
BUG= chromedriver:1772
Review-Url:
Cr-Commit-Position: refs/heads/master@{#482084}
[modify]
[modify]
[modify]
[modify]
Fixed with.
Hi.
When can we expect that released ?
Thank you and have a nice day.
The fix will be included in ChromeDriver 2.31. Its release date hasn't been determined yet.
🙏 Thank you so much! We'll keep an eye out for it then.
Agreed. Thank you very much for the effort put in to fix this.
Excellent job, thank you very much! Really looking forward to the release!
Indeed. Thanks to jzfeng@chromium.org for Making the fix!
Hi.
I thought issue is with chrome itself and not with chromedriver ?
Thank you and have a nice day.
The issue is in ChromeDriver. As its name implies, the sendKey command sends simulated key strokes to Chrome, and ChromeDriver is responsible for converting the input text string into corresponding keystrokes to send to Chrome. On Linux, ChromeDriver uses X display to do the conversion, and fails when no X display is available. The change in comment #28 adds additional code in ChromeDriver to do the text to keystroke conversion when X display isn't available.
@johnchen, is there anywhere we can get a nightly build of chromedriver that includes the patch? I have tried building it myself, but I can't seem to get a build that isn't dynamically linked to other Chrome libraries that are not shipped with the official Chrome release debs. Alternatively, can you tell me what I need to do to build it myself? I have followed [1] but not got a build of chromedriver that I can use inside my container due to the aforementioned dynamic linking issue.
[1]
I have a dockerfile that can help with making a build that isn’t linked.
@abiodun.tobi: Thanks for providing the dockerfile.
@etienne: There is no official nightly build of chromedriver, so unfortunately it's necessary to make your own build until the next release. If you make a release build of chromedriver (by adding --args="is_debug=false" option to gn command), it will have no other dependencies. Only debug build of chromedriver depends on other Chrome binaries.
Has anybody had success building chromedriver for use with CentOS 7? I have managed to build an executable using @abiodun.tobi's Dockerfile, but unfortunately it appears to require a newer glibc version than is available:
./chromedriver-2.31-dev: /lib64/libc.so.6: version `GLIBC_2.18' not found (required by ./chromedriver-2.31-dev)
I ran into the same issue trying to compile directly on a CentOS 7 machine (albeit with the error coming during the compilation stage).
Thank you for the fix. Is there is a release date for 2.31?
The release date for ChromeDriver 2.31 hasn't been determined yet.
I rented a huge server on AWS and cut a 2.31 release with this patch in it for `linux_64`. The binary is available on github here
You the man, David. Just revisited my test from above and the send_keys passed with your compiled driver. Appreciate it! I will use this until the actual release. No more xvfb!!!
Would this fix alone merit a quick release of 2.31? Seems that there's quite a few people awaiting it...
I noticed their releases can be month's apart, which seem silly to me. I would think as soon as you have something that provides some kind of value, and if it does not break backwards compatibility, and it has been tested to satisfaction, then release it right away. Actually the code should always be kept in a releasable state so releases are not a big deal and happen frequently. Although it seems this is a beast to build, which may at least partially explain their slow releases. But really I am not in the know of how or why they really do things, just speculating and sharing ideas.
I guess they have their reasons for moving at the pace they do. Fingers crossed...
The main reason we aren't able to make ChromeDriver releases as often as we (or the users) would like, is the process isn't fully automated and involves too many manual steps. We understand that this bug fix is important to many users, so we're kicking off the release process now, and we should have a release in a few days if we don't encounter any problems.
ChromeDriver 2.31 has been released and contains fix to this bug. It can be download from. Please let us know if you have any further questions. Thanks.
Thanks a lot!
Thank you.
While trying to use the latest executable, seeing this error on RHEL7.3 which was not occurring for chromedriver 2.30. Is there a runtime dependency that needs to be updated?
/usr/local/app/chromedriver: /lib64/libc.so.6: version `GLIBC_2.18' not found (required by /usr/local/app/chromedriver)
04:36:00.067 ERROR - org.apache.commons.exec.ExecuteException: Process exited with an error: 1 (Exit value: 1)
04:36:00.077 WARN - Exception thrown
java.util.concurrent.ExecutionException: org.openqa.selenium.WebDriverException: java.lang.reflect.InvocationTargetException
Thanks for releasing!
I'm also seeing the same issue as described in #52.
Chromedriver 2.31 seems to require a newer version of glibc. 2.18, while RHEL 7.3 is on 2.17.
It looks like the glibc version used by Chromium has been updated by, so any new Linux binaries built from Chromium sources would require glibc 2.18. I don't see any good way to work around that.
Because of glibc 2.18 it's looks like there is no way to use new chromedriver 2.31 on Centos 7, RHEL 7 and current Amazon Linux. What workaround would you recommend for this issue?
There is an issue created about chromedriver 2.31 at Centos 7.
Please pay attention.
Created
Ran into this with the following versions:
OS: Ubuntu 16.04
Chrome 59.0.3071.109
Chromedriver: 2.30.477691
Using ""selenium-webdriver" with python. I have attached the script. The error comes only at "element.send_keys" call.)
Hi Guys,
Ran into this with the following versions:
OS: Ubuntu 16.04
When I ran the test in server using the latest version with chrome ( 59 ), chromdriver 2.30, selenium 3.4.3, python 2.7.3 by using pyvirtualdisplay along with xvfb. My test suite hangs on while running. can you please help me to find out the root cause for why it is hanging on server machine. It's working fine on my local machine
@kandrumo
Make sure you fire up xvfb prior to running your script. Or just ditch xvfb and use chromedriver 2.31 and run headless, which is what this thread is about (your using 2.30). Since you are on Ubuntu, it should work. CentOS and some other OS's are currently having issues with 2.31.
@bens Thanks a lot!. But when i use chrome driver 2.30 and run headless mode without using xvfb. the send_keys method is not working)
@kandrumo This is exactly the bug in 2.30 (which this issue is about). You need to use 2.31 or use xvfb with 2.30.
@ i...@subotic.ch Thanks.
Will there be a chrome driver release after this fix?
I am still facing issue with sendkeys when trying to do it on new window(popup). My chrome browser version is 60.* and chrome driver version is 2.31. Any idea or workaround for this
jitendra.jogeshwar@, Please file a new bug and make sure to provide reproducible test along with the page under testing.
@jitendra, @gmanikpure.... I am still facing similar issues with sendKeys in dialogues in an SPA-app and headless chrmedriver v2.33. Looking for a workaround...