Consecutive specs using selenium hangs

[wakiki]

Another strange issue - running consecutive specs using selenium driver hangs (as in the browser window remains open, but it does not load the page). Changing to webkit driver works fine, and running individual specs using selenium works fine. Something is stopping consecutive specs running in selenium - has anyone come across this?

[abotalov]

Capybara resets sessions in After hook:
https://github.com/jnicklas/capybara/blob/master/lib/capybara/cucumber.rb#L9
https://github.com/jnicklas/capybara/blob/master/lib/capybara/rspec.rb#L14

It's done to ensure that state isn't shared between specs/scenarios

[wakiki]

Hi @abotalov - this sounds like it could be related

Currently at the top of acceptance_helper.rb I already have:

require "spec_helper"
require 'capybara/rspec'
require 'rspec-rails'

Not sure what I need to do to fix it?

Any help would be appreciated.

[abotalov]

This behavior (not preserving state from previous specs/scenarios) is intentional as it's considered a good practice to have all scenarios independent from each other.

I know a man that "fixes" that by using a fork of Capybara with rows I linked to removed

[wakiki]

Ah right I'm referring to a different issue - when running consecutive specs using the selenium driver using a command such as:

rspec spec/acceptance/some_dir/**

will open chrome, run the first spec, then the second spec will start and it will hang with a blank page in chrome. The URL will say something like 'http://127.0.0.1:8973' or some port and chrome will just have a 'loading' status and hang.

If I open another chrome browser and paste in the same URL it works fine.

Hope that makes sense and describes the problem better?

[wakiki]

After 120 secs the spec will fail with 'Timeout::Error'

[sztupy]

We're having the same issues. Sometimes when a new feature starts chrome just opens up, the URL is there, but the loader jsut keeps spinning without any response, or page loading.

[wakiki]

I never figured out what the problem was, and I had to switch to webkit instead which was a bit annoying. @sztupy if you do figure it out please do let me know thanks

[sztupy]

What operating system and version you're using?

[wakiki]

OS X Mountain lion

[sztupy]

Thought so. We didn't have problems on either Linux or OS X Lion.

[sztupy]

Just replaced chromedriver with the new chromedriver2, and modified selenium-webdriver to work with it, and I didn't had any issues since that. I uploaded the modified chromedriver-helper and selenium-webdriver gems to github:

https://github.com/sztupy/chromedriver-helper
https://github.com/sztupy/selenium-webdriver

only tested on OS X 10.8.3

[lyahdav]

We're having this same issue on OS X 10.8.4. We were using an old version of chromedriver (pre 2.0) and I upgraded it to 2.1 which at first seemed to fix this issue. But a couple days later we still got test failures of this nature, but they're intermittent. They do seem to be much more rare now, but there still seems to be something wrong and it's very hard to debug. I'm not sure this is a Capybara bug. I'm guessing it's more likely a selenium-webdriver, Chrome, or chromedriver bug.
Just a note to anyone who is having this issue and wants to upgrade to chromedriver2, you don't need to use @sztupy's forks of chromedriver-helper or selenium-webdriver anymore. It works as-is with the latest selenium-webdriver gem.

[sztupy]

You will still have the issue that you cannot (easily) set preferences (which were profiles in the previous version). Raised a bug with the webdriver guys: https://code.google.com/p/selenium/issues/detail?id=5951

Chromedriver-helper will work on linux, but not on mac or windows, as the platform's name was changed in the downloads. I uploaded chromedriver2-helper to rubygems, as it seems the original one is not updated.

And yeah, some of the bugs came back unfortunately, but it's still more stable than it was with the old chromedriver. If things worsen again I'll try to find the actual cause of the issue.

[gigiJackson]

I am running into issues with Chrome hanging randomly with Chrome=28.0.1500.95 chromedriver=2.2,platform=Mac OS X 10.8 . Gems selenium-webdriver (2.34.0), capybara (~> 2.1.0)

I've been looking at the chromedriver logs and I've noticed it seems to often follow a delete session cookie request that may be related to the session_reset that happens automatically between tests.

Similar to @wakiki, I visually observe the browser just spinning on a blank page, but if I try manually navigating in a new tab in the same Chrome session with the Capy root URL (for example http://127.0.0.1:64579/ ) the expected page renders quickly.

Exact same tests execute with no timeout errors in Firefox, and headless with phantomjs/poltergeist.

I think it's probably an issue with the chromedriver and its interaction with Capy/selenium-webdriver, so this issue may belong in the chromedriver world.

My chrome driver registration

Capybara.register_driver :selenium do |app|
          client = Selenium::WebDriver::Remote::Http::Default.new
          client.timeout = 120
          #switches = %w[--enable-logging --v=1 --ignore-certificate-errors]
          Capybara::Selenium::Driver.new(app, :browser => :chrome, :detach => :unspecified,
                                         :service_log_path => 'chromedriver.out', :http_client => client)
        end

example chromedriver log during a timeout

[0.234][INFO]: Launching chrome: /Applications/Google Chrome.app/Contents/MacOS/Google Chrome --remote-debugging-port=64590 --no-first-run --enable-logging --logging-level=1 --user-data-dir=/var/folders/7x/9shshc452xx4my0822sltdq80000gn/T/.org.chromium.Chromium.Cffmox --load-extension=/var/folders/7x/9shshc452xx4my0822sltdq80000gn/T/.org.chromium.Chromium.u4vDR1/internal --ignore-certificate-errors --metrics-recording-only data:text/html;charset=utf-8,
[0.881][INFO]: sending response: 303 
[0.885][INFO]: handling command: GET session/5ec5d112dcde96bc722901aea66f3082 
[0.885][INFO]: sending response: 200 {
   "sessionId": "5ec5d112dcde96bc722901aea66f3082",
   "status": 0,
   "value": {
      "acceptSslCerts": true,
      "applicationCacheEnabled": false,
      "browserConnectionEnabled": false,
      "browserName": "chrome",
      "chrome": {
         "chromedriverVersion": "2.2"
      },
      "cssSelectorsEnabled": true,
      "databaseEnabled": true,
      "handlesAlerts": true,
      "javascriptEnabled": true,
      "locationContextEnabled": true,
      "nativeEvents": true,
      "platform": "Mac OS X",
      "rotatable": false,
      "takesScreenshot": true,
      "version": "28.0.1500.95",
      "webStorageEnabled": true
   }
}
[0.890][INFO]: handling command: POST session/5ec5d112dcde96bc722901aea66f3082/url {
   "url": "http://127.0.0.1:64579/"
}
[1.129][INFO]: waiting for pending navigations...
[1.129][INFO]: done waiting for pending navigations
[1.386][INFO]: waiting for pending navigations...
[2.460][INFO]: done waiting for pending navigations
[2.460][INFO]: sending response: 200 {
   "sessionId": "5ec5d112dcde96bc722901aea66f3082",
   "status": 0,
   "value": null
}

...

[20.478][INFO]: sending response: 200 {
   "sessionId": "5ec5d112dcde96bc722901aea66f3082",
   "status": 0,
   "value": "Your potential reach: Calculating...\nConnect with another account below to extend your reach."
}
[20.481][INFO]: handling command: DELETE session/5ec5d112dcde96bc722901aea66f3082/cookie 
[20.481][INFO]: waiting for pending navigations...
[20.481][INFO]: done waiting for pending navigations
[20.718][INFO]: waiting for pending navigations...
[20.718][INFO]: done waiting for pending navigations
[20.719][INFO]: sending response: 200 {
   "sessionId": "5ec5d112dcde96bc722901aea66f3082",
   "status": 0,
   "value": null
}
[20.721][INFO]: handling command: POST session/5ec5d112dcde96bc722901aea66f3082/url {
   "url": "about:blank"
}
[20.721][INFO]: waiting for pending navigations...
[20.721][INFO]: done waiting for pending navigations
[21.127][INFO]: waiting for pending navigations...
[21.127][INFO]: done waiting for pending navigations
[21.127][INFO]: sending response: 200 {
   "sessionId": "5ec5d112dcde96bc722901aea66f3082",
   "status": 0,
   "value": null
}
[21.559][INFO]: handling command: POST session/5ec5d112dcde96bc722901aea66f3082/url {
   "url": "http://127.0.0.1:64579/"
}
[21.559][INFO]: waiting for pending navigations...
[21.559][INFO]: done waiting for pending navigations
[81.561][INFO]: waiting for pending navigations...
[81.561][INFO]: done waiting for pending navigations
[81.561][INFO]: sending response: 200 {
   "sessionId": "5ec5d112dcde96bc722901aea66f3082",
   "status": 13,
   "value": {
      "message": "unknown error: cannot determine loading status\nfrom timeout: timed out receiving message from renderer\n  (Session info: chrome=28.0.1500.95)\n  (Driver info: chromedriver=2.2,platform=Mac OS X 10.8...."
   }
}

[lyahdav]

I did some more research into this issue and I'm pretty convinced it's a Chrome/ChromeDriver issue. May be this same issue open on the chromedriver project: https://code.google.com/p/chromedriver/issues/detail?id=252. I get very similar output to @gigiJackson in my chromedriver output. One thing that's different for me though, I can only reproduce this issue semi-consistently when navigating to about:blank, which Capybara does from the reset_sessions! call it makes after each test (from capybara/rspec.rb).
We have two integration test suites, one which includes capybara/rspec.rb and one which doesn't. The one that doesn't never seems to have this issue, the other has it a lot.
Also this may or may not be a performance issue, as we see this issue happen a lot more often on a MacBook Air than on a MacBook Pro.
I'm going to try continuing researching this, but a workaround may be to not include capybara/rspec.rb if it's timing out for you in the reset_sessions! code path.

[lyahdav]

I can reproduce this very consistently with the following steps. I'm curious if it's not just me. First start up a rails console. Then run this setup line:
require 'capybara/dsl'; Capybara.register_driver(:selenium) { |app| Capybara::Selenium::Driver.new(app, :browser => :chrome, :service_log_path => 'chromedriver.log') }; Capybara.default_driver = :selenium; include Capybara::DSL
Then run:
10.times { |i| puts i;visit 'http://google.com';visit 'http://example.com'}
It always gets through the 10 iterations successfully.
Next run:
10.times { |i| puts i;visit 'http://google.com';visit 'about:blank'}
For me that never reaches past 3 or so without hanging, and then a Timeout::Error after 60 seconds. In chromedriver.log I see that it hangs when loading about:blank with the text 'waiting for pending navigations...'. If I go to the hung browser and click on the address bar and press enter (within 60 seconds of it hanging) it unhangs it, but only until the next iteration.

This is with Chrome version 28.0.1500.95 and chromedriver 2.1.

Interestingly enough, if I run:
10.times { |i| puts i;visit 'http://example.com';visit 'about:blank'}
It always succeeds. The main difference I can think is that http://google.com does a redirect but http://example.com doesn't. That may or may not be related to this issue.

Again this seems like a Chrome/chromedriver bug, but like I mentioned in my last comment a workaround is to not let Capybara run reset_sessions!. This is actually more complicated than not requiring 'capybara/rspec' as I implied in the previous comment. The way I got around it is to keep the require for 'capybara/rspec' in spec_helper.rb but right after it add:

module ::Capybara
  def self.reset_sessions!
  end
end

I realize this is super hacky, and it might not work for everyone if you're relying on cookies getting cleared or it navigating to about:blank in between tests.

I'll continue to investigate this when I have more time. Any other help would be greatly appreciated.

[andrew-david-smith]

Yeah I get Net::ReadTimeout errors with chromedriver v2.2 and Chrome 29.

It wont fail all of the time, but it rarely manages to get past two scenarios inside a cucumber feature.

lyahdav's hacky solution works for me, and will be what I use for the moment.

[jdelStrother]

For what it's worth, I filed a bug on this : https://code.google.com/p/chromedriver/issues/detail?can=2&start=0&num=100&q=&colspec=ID%20Status%20Pri%20Owner%20Summary&groupby=&sort=-id&id=502

I can reproduce it without Capybara :

require 'rack/handler/webrick'
require 'selenium-webdriver'
require 'rack'

class Selenium::WebDriver::Chrome::Bridge
  def extract_service_args(args)
    ["--log-path=chromedriver.log", "--verbose"]
  end
end

Thread.new{
  app = proc { |env| [200, {}, ["Hello Server! #{env['PATH_INFO']}"]]}
  Rack::Handler::WEBrick.run(app, :Port => 22790)
}

# Make sure the server has started
loop do
  begin
    break if Net::HTTP.start('127.0.0.1', 22790) { |http| http.get('/') }.is_a?(Net::HTTPSuccess)
  rescue SystemCallError
    sleep 0.01
  end
end


loop do
  browser = Selenium::WebDriver.for(:chrome)
  puts Time.now
  browser.navigate.to "http://127.0.0.1:22790/1"
  browser.navigate.to('about:blank')
  browser.quit
end

... that said, it does seem to be Capybara's navigating to about:blank that triggers the bug - I don't think I've seen it occur on visiting a regular page. Weird.

[kippr]

I was banging my head against the monitor with this issue yesterday. Finally I found a workaround fix by observing the chromedriver logs showing that the network call to tell chromedriver to navigate to "about:blank" was never returning. (My google-fu was weak yesterday, only found this thread today.)

I patched the reset method (https://github.com/jnicklas/capybara/blob/master/lib/capybara/selenium/driver.rb#L90) to navigate to 'about:help' instead and all works.

I also noticed that the HEAD shutdown command was being ignored by chromedriver yesterday and I was accumulating Chrome instances, but this morning its working again. Its raining outside today, maybe that's the difference?

I'll try chromedriver2 today if I can muster the will...

Oh yeah and if anyone else has as much difficulty enabling chromedriver logging as I did (trawling through the selenium source code finally to find out how), here you go:

    Capybara.register_driver :chrome do |app|
          Capybara::Selenium::Driver.new(app, :browser => :chrome,  :service_log_path => 'chromedriver.log')
    end

This is the only config you can pass to chromedriver as it stands (see https://code.google.com/p/selenium/source/browse/rb/lib/selenium/webdriver/chrome/bridge.rb#105) 😿

This was 100% consistently failing on:
macbook pro retina 10.8.4,
Capybara 2.1.0 (and now master)
selenium-0.2.10
selenium-webdriver-2.35.1
chromedriver 2.3 (auto update broke old driver, so I moved to latest chromedriver via brew, not sure if there is a gem?)
chrome 29.0.1547.65... and maybe i'll be turning that autoupdating off 💩

Cheers
Kris

[tgaff]

Also reproduced same behavior:
selenium-webdriver 2.35.0
capybara 2.1.0
chromedriver 2.3
on mountain lion

The about:help hack seems to work though.

[rhuberdeau]

I was able to reproduce the issue was well:
selenium-webdriver 2.35.0
capybara 2.1.0
chromedriver-win32 2.3
Windows 7

The about:help hack fixed the issue.

[jnicklas]

For those of you having problems with this, could you try creating an empty file, and then trying to navigate to file:///path/to/file? I think this might be a sensible alternative to about:blank, since that seems to be causing issues.

[brettporter]

@jnicklas yes, that works, as does using a filename that doesn't exist.

[rhuberdeau]

@jnicklas navigating to a file worked for me as well, and as brettporter noted, as does navigating to a file that does not exist.

[brettporter]

@jnicklas I just updated chromedriver to 2.4 (with Chrome 30.0) and the problem seems to have gone away, as did a problem I was having with a click event. The release notes indicate it supports Chrome 29.0 - 32.0, so perhaps the problem highlighted by recent commenters was chromedriver 2.3 + Chrome 29.0+?

Incidentally, I noted that chromedriver starts on the URL data:,, which might be another alternative to consider if needed.

[jnicklas]

Just pushed a fix for this, please give it a try, especially if any of you are on Windows.

[mickeyreiss]

Hi @jnicklas! I noticed that 6b1e42d hard codes a local file system path. In my test suite, rspec/capybara/webdriver are running in a virtualbox, and only firefox and selenium are running on the local Mac. As a result, I see firefox's file not found error in between each test. Do you have any suggestions for working around this issue?

[jnicklas]

Yeah, this solution has turned out to be problematic. I'll work on pushing a fix for it ASAP. If anyone has a suggestion on how to do this better, I'd love to hear it.

[brettporter]

@jnicklas how about data:text/html, instead? This works in Safari, Chrome and Firefox here. (data:, works in the last two only).

[nsocheleau]

In the server middleware, you have a special path '/identity' to check for the responsiveness of the server.
You could have a path '/empty' to load the empty html page. When resetting the driver, you would visit ('/empty'), remote drivers wouldn't have to load that local file.

[jnicklas]

It seems that #1214, #1203, and #1198, are all related to this. I'll try to fix this using the data: suggestion, that seems like a good fix, but I don't have the setup available to test this on Windows, and I don't have time to set it up. So if someone here can test this on windows, that'd be super. Working on a patch now.

[jdelStrother]

What's visiting the empty page trying to achieve? What about just deleting the code that does so?

[kippr]

Hi Jonas

I have a Windows VM I can test this on. Let me know when the patch is ready.

Would you like me to test with a particular version of selenium/ chrome/ chromedriver?

Cheers
Kris

[jnicklas]

@jdelStrother there are multiple reasons for doing this, for one, it cancels all active Ajax requests, which prevents a lot of ugly race conditions on cleanup. Also, it prevents state from bleeding over between test cases, which is generally what you want.

[jnicklas]

Hey guys, I have pushed #1215 which is a potential fix for this, would appreciate it a lot if someone with a Windows setup could test this out! /cc @kippr.

[kippr]

Hmm, unfortunately I'm getting errors between each test now. With the local file solution I was also getting errors when running IE tests remotely on Windows 7 from my mac :(

Rolling back to the about:help still works for me on IE.

Below is the selenium error message. As you can see its a remote test i'm running.

    Failure/Error: Unable to find matching line from backtrace
     Selenium::WebDriver::Error::NoSuchElementError:
       Finding elements returned an unexpected error (WARNING: The server did not provide any stacktrace information)
       Command duration or timeout: 264 milliseconds
       For documentation on this error, please visit: http://seleniumhq.org/exceptions/no_such_element.html
       Build info: version: '2.32.0', revision: '6c40c18', time: '2013-04-09 17:22:56'
       System info: os.name: 'Windows 7', os.arch: 'x86', os.version: '6.1', java.version: '1.7.0_17'
       Session ID: 0381e13d-9b0e-45cf-bffa-2e8667cbcafa
       Driver info: org.openqa.selenium.ie.InternetExplorerDriver
       Capabilities [{platform=WINDOWS, elementScrollBehavior=0, javascriptEnabled=true, enablePersistentHover=false, ignoreZoomSetting=false, browserName=internet explorer, enableElementCacheCleanup=true, unexpectedAlertBehaviour=dismiss, version=9, cssSelectorsEnabled=true, ignoreProtectedModeSettings=false, allowAsynchronousJavaScript=true, requireWindowFocus=false, handlesAlerts=true, initialBrowserUrl=, nativeEvents=false, takesScreenshot=true}] (org.openqa.selenium.NoSuchElementException)
     # [remote server] sun.reflect.NativeConstructorAccessorImpl():-2:in `newInstance0'
     # [remote server] sun.reflect.NativeConstructorAccessorImpl():-1:in `newInstance'
     # [remote server] sun.reflect.DelegatingConstructorAccessorImpl():-1:in `newInstance'
     # [remote server] java.lang.reflect.Constructor():-1:in `newInstance'
     # [remote server] org.openqa.selenium.remote.ErrorHandler(ErrorHandler.java):187:in `createThrowable'
     # [remote server] org.openqa.selenium.remote.ErrorHandler(ErrorHandler.java):145:in `throwIfResponseFailed'
     # [remote server] org.openqa.selenium.remote.RemoteWebDriver(RemoteWebDriver.java):554:in `execute'
     # [remote server] org.openqa.selenium.remote.RemoteWebDriver(RemoteWebDriver.java):332:in `findElements'
     # [remote server] org.openqa.selenium.remote.RemoteWebDriver(RemoteWebDriver.java):408:in `findElementsByXPath'
     # [remote server] org.openqa.selenium.By$ByXPath(By.java):339:in `findElements'
     # [remote server] org.openqa.selenium.remote.RemoteWebDriver(RemoteWebDriver.java):295:in `findElements'
     # [remote server] sun.reflect.GeneratedMethodAccessor70():-1:in `invoke'
     # [remote server] sun.reflect.DelegatingMethodAccessorImpl():-1:in `invoke'
     # [remote server] java.lang.reflect.Method():-1:in `invoke'
     # [remote server] org.openqa.selenium.support.events.EventFiringWebDriver$2(EventFiringWebDriver.java):101:in `invoke'
     # [remote server] com.sun.proxy.$Proxy1():-1:in `findElements'
     # [remote server] org.openqa.selenium.support.events.EventFiringWebDriver(EventFiringWebDriver.java):169:in `findElements'
     # [remote server] org.openqa.selenium.remote.server.handler.FindElements(FindElements.java):48:in `call'
     # [remote server] org.openqa.selenium.remote.server.handler.FindElements(FindElements.java):1:in `call'
     # [remote server] java.util.concurrent.FutureTask$Sync():-1:in `innerRun'
     # [remote server] java.util.concurrent.FutureTask():-1:in `run'
     # [remote server] org.openqa.selenium.remote.server.DefaultSession$1(DefaultSession.java):169:in `run'
     # [remote server] java.util.concurrent.ThreadPoolExecutor():-1:in `runWorker'
     # [remote server] java.util.concurrent.ThreadPoolExecutor$Worker():-1:in `run'
     # [remote server] java.lang.Thread():-1:in `run'

[jnicklas]

Damnit.

[kippr]

Reading the comment from @brettporter above, I went back and tested the original implementation (using about:blank) and can confirm that with the latest chrome (31.0.1650.63)/ chromedriver (homebrew installed v2.7.236836)/ osx (10.9.1), about:blank no longer hangs between tests.

So you might be able to roll back and forget about this whole frustrating episode?

[jnicklas]

Okay, let's go for it.

[jnicklas]

I've pushed 2.2.1 with this fix to Rubygems, let me know if anyone has further problems with this.

[mickeyreiss]

🌵 Thanks @jnicklas! We'll try this out and will let you know if there are any problems.

[kippr]

Tested on a setup with the original problem (running local tests with Chrome on OSX) and on a setup that didn't like the above fix (remote tests with IE on Windows 7 VM).

Can confirm all is hunky dory now, thanks v much for the great project @jnicklas!

[alekstkach]

I confirm there is a problem with Timeout::Error on IE+Win7, visit and click methods, browser hangs and fails with Timeout::Error.

[vgrigoruk]

The issue seems to be reproducible again on Ubuntu with:

• ChromeDriver 2.10.267518
• Google Chrome 36.0.1985.143
• Capybara 2.4.3

Issues is related to https://code.google.com/p/chromedriver/issues/detail?id=700,
But it will be good to have some kind of quick workaround in Capybara, until the issue is fixed in chromediriver.

[jdelStrother]

FWIW, the chrome/chromedriver bug appears to be fixed now - https://code.google.com/p/chromedriver/issues/detail?can=2&start=0&num=100&q=&colspec=ID%20Status%20Pri%20Owner%20Summary&groupby=&sort=&id=502. Not sure if we want to revert back to just using about:blank anytime soon?