Latest version of chrome causes capybara specs to fail with Net::ReadTimeout #2181
Comments
|
Also experiencing this on Capybara 2.18.0 (Rails 3.2). We're using the On macOS, we are able to work around this by following these steps:
|
|
Possibly the same as https://bugs.chromium.org/p/chromedriver/issues/detail?id=2878? |
|
Sample failure, using rails 5.0.7.2: |
|
If it works fine with Chrome 73 but 74 times out that would tend to imply an issue with Chrome of chromedriver. Without a way to replicate the issue I can't even really attempt to diagnose anything. Capybaras test suite runs against Chrome 74 without issue - https://travis-ci.org/teamcapybara/capybara/jobs/525827115 . If someone can provide a way to replicate I can look further ... |
|
This is the config that I'm using, if that helps: require 'selenium/webdriver'
Capybara.default_max_wait_time = 5
Capybara.register_driver :chrome do |app|
Capybara::Selenium::Driver.new(app, browser: :chrome)
end
Capybara.register_driver :headless_chrome do |app|
capabilities = Selenium::WebDriver::Remote::Capabilities.chrome(
chromeOptions: { args: %w(headless disable-gpu window-size=1280,2000 no-sandbox) }
)
Capybara::Selenium::Driver.new app,
browser: :chrome,
desired_capabilities: capabilities
end
Capybara.javascript_driver = :headless_chromeI have noticed that when I remove headless from chromeOptions, it works. It very well may be a chrome / chromedriver issue. |
|
Here's another sample config: require 'webdrivers'
require 'selenium-webdriver'
Capybara.register_driver :chrome do |app|
Capybara::Selenium::Driver.new(app, browser: :chrome)
end
Capybara.register_driver :headless_chrome do |app|
capabilities = Selenium::WebDriver::Remote::Capabilities.chrome(
chromeOptions: { args: %w(headless window-size=1024,768) },
loggingPrefs: { browser: 'ALL' }
)
Capybara::Selenium::Driver.new app,
browser: :chrome,
desired_capabilities: capabilities
end
Capybara.default_max_wait_time = 5
Capybara.javascript_driver = :headless_chrome # :chrome simulates behavior in browser
Capybara.server_port = 31337 + ENV['TEST_ENV_NUMBER'].to_i
Capybara.configure do |config|
config.always_include_port = true
endAnd the basic test case is (with Chrome 74, and require "spec_helper.rb"
visit "/" |
|
@bgwilson87 @iwz Can you try adding the |
@twalpole this does not make a difference for me. |
|
@iwz Ok then I think it's a chromedriver issue where there's nothing Capybara can really do about it. It doesn't affect the Capybara tests on travis or locally for me on MacOS 10.14.4 so it's possible it's a platform specific issue in chromedriver. Does it occur in the same code location for you? (in session reset when Capybara is asking chromedriver for a list of the open windows) If so, you're not doing something like closing all the open windows inside a test that could cause chromedriver to hit an edge case?? |
|
I have opened an issue in chromedriver here https://bugs.chromium.org/p/chromedriver/issues/detail?id=2885 |
|
The following Ruby code didn't reproduce this issue: Selenium::WebDriver::Chrome.driver_path = File.join("<path_to_v74_chromedriver>/chromedriver") |
|
Update I've since replaced the following workaround with ar31an's fix. There is a workaround: disable |
|
We are also experiencing this issue with all versions 3.16 and above let me know if you need further information. |
|
@RaipheKelsch The further information we need is a self contained way to reproduce this issue. As stated above the Capybara test suite runs fine against Chrome/chromedriver 74 on TravisCI (in both headless and headed configurations). Since you've mentioned Capybara 3.16. It made a change over to using a persistent connection which could theoretically cause issues if you are running against remote connections that prevent persistent connections for some reason, however I believe that would be a different issue than the one being discussed here and in that environment would probably affect more than just chromedriver 74. |
|
it seems the Chrome 74 upgrade broke my tests as well. I'm seeing this error: Chrome auto-updated to Version 74.0.3729.131 I tried downgrading to v72 using the link from @iwz's post above, installed it, my tests passed, but I was unable to launch Chrome on my mac with that version (it showed some error telling me "Chrome is damaged, move it to trash". So now I'm back to running the latest Chrome version, and all my JS tests fail... Waiting for someone to provide instructions on what to do! |
|
@CasJam The chromedriver version you’re using needs to match the chrome version . If you’re using Chrome 74.x you need chromedriver 74.x to go with it |
|
Update: I've since replaced the following workaround with the ar31an's fix. Original: I've found a work-around that is sufficient for my needs; it may help others: The issue appears to happen whenever a page has some sort of external dependency (an asynchronous script, or an iframe with content from another domain, for example). I am not sure, but suspect it may be whenever an cookie for an external domain is set. I am, however, reasonably sure this is in fact an issue with Chrome or Chrome Driver, and not Capybara. If anyone wishes to debug the underlying cause or develop a better workaround the one above, you can configure the chrome driver to log out to file, like so: |
|
@CasJam, you may also find it useful to temporarily enable the webdriver gem's logging to confirm what version of the Chrome webdriver you are using (it will log as much to the console the next time you run your test suite): |
|
@greena13 I'm trying to implement your patch, but I don't know where to put this file... I tried |
|
@pixiitech, I put it in a file in the /spec/support/ directory and then required that file in /spec/spec_helper.rb. I don't have the code in front of me at the moment, but you may need to play around with the order that you require it relative to where you require capybara. |
|
@greena13 Thanks for that patch! I was about to eat my keyboard. It works for me. |
|
@greena13 Are you running against a remote instance of Chrome, or a local one? With a local chrome instance and a relatively current version of selenium-webdriver the workaround you posted should never actually be called. |
|
@greena13 your patch didn't work for me unfortunately :-( I'm still stuck with timeouts in my local development. However, tests run fine on Heroku CI using https://github.com/heroku/heroku-buildpack-google-chrome and https://github.com/heroku/heroku-buildpack-chromedriver which in turn download the latest chrome and chromdriver (logs says I'm looking into it further as time allows and will post any findings here... |
|
Quick update - after having tried with chrome beta (v75) I reinstalled stable (v74), downloaded chromedriver v74.0.3729.6 and moved it to I can't explain what happened though. My configuration: The |
|
I solved this on CircleCI by pinning my container to the last hash that worked and using chromedriver-helper to install chromedriver 73. version: 2
jobs:
build:
docker:
- image: circleci/jruby@sha256:66e1c96d6836cd0c2edbd81570f370e798e0d770a84a3d42df38967709eb9082
environment:
JRUBY_OPTS: --dev -Xcompile.invokedynamic=true -J-XX:+UseCodeCacheFlushing
-J-Xmx1g
RAILS_ENV: test
RACK_ENV: test
working_directory: ~/repo
steps:
- checkout
- restore_cache:
keys:
- v1-dependencies-{{ checksum "Gemfile.lock" }}
- v1-dependencies-
- run:
name: install dependencies
command: |
sudo apt install make gcc g++
bundle install --jobs=4 --retry=3 --path vendor/bundle \
--without development doc production
- save_cache:
paths:
- ./vendor/bundle
key: v1-dependencies-{{ checksum "Gemfile.lock" }}
- run:
name: run tests
command: |
google-chrome --version
bundle exec chromedriver-update 73.0.3683.68
bundle exec chromedriver-helper --version
mkdir /tmp/test-results
TEST_FILES="$(circleci tests glob "spec/**/*_spec.rb" | circleci tests split --split-by=timings)"
bundle exec rspec --format progress \
--format RspecJunitFormatter \
--out /tmp/test-results/rspec.xml \
$TEST_FILES |
|
I have had the same issue with capybara specs on mac. Adding this argument solved the issue:
Reference: https://bugs.chromium.org/p/chromedriver/issues/detail?id=2897#c4 My configuration: |
|
Update: See ar31an's post above instead, unless you want to avoid auto-updates in future, it fixes the problem instead of avoiding it. -- I've been getting weird test failures since Chrome 74 installed itself (initially the Net::ReadTimeout, then after moving to webdrivers it just broke content based browser synchronisation or introduced some session cleanup race condition vs running without headless) and would like to suggest another work-around for people who don't have a Docker/VM testing setup. It unfortunately does nothing to help find or fix the problem, but might save someone else some time. Chromium: A Downgrading SolutionOld Chrome versions aren't officially made available, and getting it from a third party is dangerous. We've got another option though: Chromium, which does make old builds available. And they don't auto-update. I've used this approach on my Mac to get my tests running locally again without having to remove the headless flag. This is suitable for folk who want their tests to run and don't care which browser/version they run in, but don't want to spend time re-stabilising their tests in headless Firefox. This assumes use of the
My specific setup code is this before registering my capybara drivers: And a dotenv file
I like this .env approach because switching back to Chrome is as simple as removing that line from the dotenv file, which is gitignored and will only affect my installation. No need to commit/share anything. It does mean each developer will need to do it independently though so YMMV. Security Disclaimer: using an old unofficial browser build is introducing a security flaw in your system. Consider firewalling/sandboxing it if you can. In my case I'm restricting its network access to where I expect my tests to go with LittleSnitch. |
|
For those using Heroku, I just wanted to combine what @ar31an and @jeppeliisberg mention above in case you need another example. Adding the additional argument to the code that Heroku provide in their Google Chrome buildpack documentation resolved my issue locally without needing to install Chrome Beta and it continued to work on Heroku . Here's the configuration that worked for me: require "selenium/webdriver"
chrome_bin = ENV.fetch('GOOGLE_CHROME_SHIM', nil)
chrome_opts = chrome_bin ? { "chromeOptions" => { "binary" => chrome_bin } } : { chromeOptions: { args: ['headless', 'disable-gpu', '--enable-features=NetworkService,NetworkServiceInProcess'] } }
Capybara.register_driver :chrome do |app|
Capybara::Selenium::Driver.new(
app,
browser: :chrome,
desired_capabilities: Selenium::WebDriver::Remote::Capabilities.chrome(chrome_opts)
)
end
Capybara.javascript_driver = :chromeHope that helps someone! |
|
Since I haven't been able to reproduce this issue in any of my environments, has anyone that experienced this issue with Chrome 74 tried Chrome 75? If so is the issue solved on 75 without needing the NetworkService and NetworkServiceInProcess options? |
|
I've been experiencing this issue since about two weeks, but with chromium and chromedriver 73, in both headless and non-headless mode (where the chromium and chromedriver run in a Docker container). Locally I observe many sockets (running in the thousands after a while) in TIME_WAIT, reminiscent of earlier problems with correctly closing connections or lack of keepalive. Started happening after upgrade of capybara and selenium-webdriver from Capybara 3.12.0 and selenium-webdriver 3.11.0 to Capybara 3.18.0 and selenium-webdriver 3.142.0. But that may be circumstantial, because that was part of a major upgrade of all gems. And of course chrome also keeps evolving. Edit: I can reproduce the issue with Capybara 3.12.0 and selenium-webdriver 3.11.0, so those upgrades aren't the issue. |
|
@Confusion If you're using Chrome/chromedriver 73 it's a different issue than this thread is talking about (which is for 74). Since you're running in a container it's probable you need to specify a combination of chrome options such as |
|
@ar31an 's solution worked (adding |
|
Closing this since it is a chrome/chromedriver issue, with an available fix, and not a Capybara issue |
|
I was struggling with I tried all of the options that were mentioned, but these didn't help: Was still getting (It did work if I ran as the root user in my Docker container, or if I used the The solution was to upgrade from capybara |
|
@ndbroadbent I'm glad to hear things are working for you, but there really is nothing between 3.22 and 3.24 - 3.22.0...3.24.0 - that should have any affect on network timeouts. Are you 100% sure no other gem / chrome / chromedriver updates occurred?? |
|
@twalpole You're right, I downgraded That's very weird, because the tests did start passing immediately after I ran So I think this is probably just a weird Docker issue, and Chrome wasn't able to start properly in the container. So if anyone else runs into that, I guess try restarting Docker first, or rebuild your images. |
New version of chrome (74) hangs and eventually dies with Net::ReadTimeout. Downgrading to 73 fixes the issue.
Meta
Capybara Version: 3.4.0
Driver Information (and browser if relevant):
Chrome 7.
Actual Behavior
Specs work.
Steps to reproduce
Run any javascript spec
The text was updated successfully, but these errors were encountered: