Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

Capybara-webkit stops / hangs unexpectedly and inconsistently #399

mattheworiordan opened this Issue Oct 17, 2012 · 60 comments


None yet

Firstly, I appreciate how hard it is to debug this issue, or even figure out if Capybara-webkit is indeed at fault, but I believe Capybara-Webkit, QT Webkit, and or Capybara are causing the problem, with the former two being the more likely. So I appreciate any help if you can help.

I am on OS X 10.8.1 with the latest version of all gems, QT webkit 4.8.3 and Ruby 1.9.3 available. I'll post the info further down for your reference.

I have found that recently after upgrading my OS and installing the latest QT & Capybara-webkit Gem, when running a few small Cucumber tests using rake cucumber:wip everything tends to work fine. However, when I run the full suite I find the tests just hang for some reason, and never fix themselves. I have seen this in my CI environment (Mac as well, but OS OX 10.7, and latest versions of everything else) as well. However, if I set Capybara.javascript_driver = :selenium instead of Capybara.javascript_driver = :webkit then I don't experience this behaviour

I can reproduce this error easily by running rake cucumber, the first 34 scenarios across 5 feature files run OK, and then oddly when I hit the 6th feature file (one of many more), it hangs on the first scenario before what seems like Capybara-Webkit has even been invoked. However, clearly it is because when Selenium is used this issue does not exist.

Here is the output from the test on that scenario showing, and importantly it does not seem like the @javascript interpretor has yet been invoked (I use capybara-webkit) as it got stuck on the Background portion:

Feature: Backlog Other Functionality
  In order to manage a backlog
  A visitor
  Should be able to rely on some necessary functionality

  Background:                                                                                      # features/backlog_other.feature:6
    Given the database has the necessary lookup tables                                             # features/step_definitions/shared_steps.rb:1
    And a user named "John" is registered                                                          # features/step_definitions/authentication_steps.rb:1

The @javascript declaration in fact comes later in the scenario declaration, not in the background section, so to be honest I'm not sure if Capybara detects that in advance and switches to the :javascript driver, or if it only switches when the Scenario starts that is tagged with @javascript.

Anyway, clearly it is hanging on the next step in the Background which is And I am signed in as "John"
The code for this step is as follows:

step %{I am on the home page}
step %{I follow "Log in"}
step %{I fill in "Email" with "#{user_name.gsub(/ /,'')}@acme.com"}
step %{I fill in "Password" with "password"}
step %{I press "Log in"}
step %{I should see the notice "Signed in successfully."}

Now I could include all the code for this step if you want, but it's all pretty bog standard Capybara code. For example, here are two of the steps:

Given /^(?:|I )am on (.+)$/ do |page_name|
  visit path_to(page_name)

When /^(?:|I )follow "([^"]*)"(?: within "([^"]*)")?$/ do |link, selector|
  with_scope(selector_to(selector)) do

So why it should hang on this step confuses me. There is certainly nothing in those steps that warrants any odd behaviour, and if I run that test individually it works just fine.

I have included a debug log using Capybara.javascript_driver = :webkit_debug for:

  • A full rake cucumber which fails every time and hangs - please see capybara-webkit.log
  • rake cucumber:wip which runs the same scenario tagged with @wip that fails when run as part of rake cucumber - please see capybara-webkit-wip.log

So why it works on its own, and not with others is beyond me.

Looking at the log it seems that it gets stuck at the last line

Oddly however, whilst it is hung, I run the following command and it responds just fine:
$ curl -I
HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
X-Ua-Compatible: IE=Edge,chrome=1
Etag: "5ea29e44392cd954eb3c57e2464ad3b0"
Cache-Control: max-age=0, private, must-revalidate
X-Request-Id: 408a00e6fcecefc59c7837b6f9215d79
X-Runtime: 0.035834
Server: WEBrick/1.3.1 (Ruby/1.9.3/2012-04-20)
Date: Wed, 17 Oct 2012 17:04:18 GMT
Content-Length: 0
Connection: Keep-Alive
Set-Cookie: _easybacklog_session=BAh7B0kiD3Nlc3Npb25faWQGOgZFRkkiJTdlMzBhZTFkODEyZDRjYmQ0ZDMyNDAyNTBmZjk1OWJkBjsAVEkiDWxhc3RfdXJsBjsARkkiBi8GOwBG--ac40a5343fc67f1e0d8563994c10a068839ef97e; path=/; HttpOnly

Here is some info on my environment:

OS X Version: 10.8.1
Ruby: ruby-1.9.3-p194 using RVM
XCode version: 4.5.1

$ gcc --version
i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.11.00)

$ bundle list
Gems included by the bundle:

  • Ascii85 (1.0.2)
  • ZenTest (4.8.2)
  • actionmailer (3.2.8)
  • actionpack (3.2.8)
  • activemodel (3.2.8)
  • activerecord (3.2.8)
  • activeresource (3.2.8)
  • activesupport (3.2.8)
  • acts_as_list (0.1.8)
  • addressable (2.3.2)
  • arel (3.0.2)
  • autotest (4.4.6)
  • autotest-growl (0.2.16)
  • autotest-rails (4.1.2)
  • awesome_print (1.1.0)
  • bcrypt-ruby (3.0.1)
  • builder (3.0.3)
  • bundler (1.2.0)
  • capybara (1.1.2)
  • capybara-screenshot (0.2.2)
  • capybara-webkit (0.12.1)
  • childprocess (0.3.5)
  • chunky_png (1.2.6)
  • coderay (1.0.8)
  • columnize (0.3.6)
  • compass (0.12.2)
  • compass-960-plugin (0.10.4)
  • compass-rails (1.0.3)
  • cucumber (1.2.1)
  • cucumber-rails (1.3.0)
  • database_cleaner (0.9.1)
  • debugger (1.2.0)
  • debugger-linecache (1.1.2)
  • debugger-ruby_core_source (1.1.3)
  • deep_merge (1.0.0)
  • devise (2.1.2)
  • devise-encryptable (0.1.1)
  • diff-lcs (1.1.3)
  • ejs (1.1.1)
  • email_spec (1.2.1)
  • erubis (2.7.0)
  • exceptional (2.0.32)
  • excon (0.16.4)
  • execjs (1.4.0)
  • factory_girl (4.1.0)
  • factory_girl_rails (4.1.0)
  • ffi (1.1.5)
  • foreman (0.60.0)
  • fssm (0.2.9)
  • gherkin (2.11.4)
  • growl (1.0.3)
  • haml (3.1.7)
  • hashery (2.0.1)
  • heroku (2.32.11)
  • heroku-api (0.3.5)
  • heroku_san (3.0.4)
  • hike (1.2.1)
  • hpricot (0.8.6)
  • httparty (0.9.0)
  • i18n (0.6.1)
  • journey (1.0.4)
  • jquery-rails (2.1.3)
  • jslint_on_rails (1.1.1)
  • json (1.7.5)
  • kgio (2.7.4)
  • launchy (2.1.2)
  • libwebsocket (0.1.5)
  • mail (2.4.4)
  • method_source (0.8)
  • mime-types (1.19)
  • multi_json (1.3.6)
  • multi_xml (0.5.1)
  • netrc (0.7.7)
  • newrelic_rpm (3.4.2)
  • nokogiri (1.5.5)
  • orm_adapter (0.4.0)
  • pdf-reader (1.2.0)
  • pg (0.14.1)
  • polyglot (0.3.3)
  • prawn (0.12.0)
  • pry (0.9.10)
  • pry-rails (0.0.4 6dd39e3)
  • quiet_assets (1.0.1)
  • rack (1.4.1)
  • rack-cache (1.2)
  • rack-force_domain (0.2.0 ff16ac9)
  • rack-ssl (1.3.2)
  • rack-test (0.6.2)
  • rails (3.2.8)
  • railties (3.2.8)
  • raindrops (0.10.0)
  • rake (
  • rdoc (3.12)
  • recursive-open-struct (0.2.2 8178fa5)
  • redis (2.2.2)
  • redis-namespace (1.0.3)
  • rest-client (1.6.7)
  • rspec (2.11.0)
  • rspec-core (2.11.1)
  • rspec-expectations (2.11.3)
  • rspec-mocks (2.11.3)
  • rspec-rails (2.11.0)
  • ruby-rc4 (0.1.5)
  • ruby_parser (2.3.1)
  • rubyzip (0.9.9)
  • sass (3.2.1)
  • sass-rails (3.2.5)
  • selenium-webdriver (2.25.0)
  • sequel (3.20.0)
  • sexp_processor (3.2.0)
  • shortly (0.3.3)
  • shoulda-matchers (1.4.0)
  • sinatra (1.0)
  • slop (3.3.3)
  • sprockets (2.1.3)
  • taps (0.3.24)
  • thor (0.16.0)
  • tilt (1.3.3)
  • timecop (0.5.2)
  • treetop (1.4.11)
  • ttfunk (1.0.3)
  • turbo-sprockets-rails3 (0.1.15)
  • tzinfo (0.3.33)
  • uglifier (1.3.0)
  • unicorn (4.3.1)
  • vanity (1.8.0 dda319f)
  • warden (1.2.1)
  • watchr (0.7)
  • webrat (0.7.3)
  • will_paginate (3.0.3)
  • xml-object (0.9.93)
  • xpath (0.1.4)

$ brew info qt

qt: stable 4.8.3 (bottled), HEAD
/usr/local/Cellar/qt/4.8.2 (2753 files, 195M)
/usr/local/Cellar/qt/4.8.3 (2779 files, 194M) *
==> Options
  Compile and link Qt with developer options
  Enable deprecated Qt3Support module
  Compile Qt in debug and release mode
  Enable QtDBus module
  Build a universal binary
  Enable MySQL plugin
  Enable Qt demos and examples
==> Caveats
We agreed to the Qt opensource license for you.
If this is unacceptable you should uninstall.

BTW. I just tried uninstalling and installing Qt and installling with version 4.8.2 and I had the same issue.


mhoran commented Oct 24, 2012

Please check out the latest master and see if it resolves your issues. We just pushed a number of fixes for Qt 4.8.

Sorry, unfortunately it doesn't work :(

It gets stuck on this line in my Cucumber steps now, which is different admittedly:

Scenario: Duplicate a backlog # features/backlog.feature:33
When I follow "Create a new backlog" # features/step_definitions/web_steps.rb:27
And I fill in "Name the backlog" with "Project X" # features/step_definitions/web_steps.rb:33
And I press "Create new backlog" # features/step_definitions/web_steps_extra.rb:1

xn commented Nov 9, 2012

Looks like a co worker and myself are getting the same issue.


jferris commented Nov 9, 2012

@mattheworiordan can you paste a log from the webkit_debug driver using master? The debugging output is much better for this kind of thing now.

Ok, will do.

On 9 Nov 2012, at 18:10, Joe Ferris notifications@github.com wrote:

@mattheworiordan can you paste a log from the webkit_debug driver using master? The debugging output is much better for this kind of thing now.

Reply to this email directly or view it on GitHub.

xn commented Nov 9, 2012

Where is this log? just the rails test.log?

@jferris, here is the log when running cucumber


jferris commented Nov 9, 2012

@mattheworiordan do you know what's going on in your code when that happens? It seems like maybe it's starting some requests and then canceling them somehow, and capybara-webkit doesn't realized that the request has been canceled.

Here are the 4 steps of my scenario, it seems the final one never fires, or perhaps it hangs on this step:

When I follow "Create a new backlog"
  And I fill in "Name the backlog" with "Project X"
  And I press "Create new backlog"
Then I should see the notice "Backlog was successfully created."

And I press "Create new backlog" simply executes the following code:

When /^(?:|I )press "([^"]*)"(?: within (?:|the )"([^"]*)")?$/ do |button, selector|
  selector_css = selector_to(selector)
  sleep 0.2 if selector_css.present? && !page.has_css?(selector_css) # https://github.com/thoughtbot/capybara-webkit/issues/36
  with_scope(selector_css) do
    click_button(selector_to(button, :dont_translate_to_css=>true))

Then I should see the notice "Backlog was successfully created." executes the following code:

Then /^(?:|I )should (|not )see the (notice) "([^"]+)"$/ do |negation, notice_alert, message|
  selector = "#alert-space .#{notice_alert}"
  unless negation.strip == "not" && page.has_no_selector?(selector) # if notice not shown at all allow this to pass if in the negative
    within(selector) do |content|
      if negation.strip == "not"
        page.should_not have_content(message)
        page.should have_content(message)

To be honest, I can't see anything particularly unusual in any of this?

Not sure what else I can provide. I appreciate you looking into this, it's a really odd problem.


jferris commented Nov 9, 2012

Can you use $stdout.puts statements to track down exactly which line it's halting on? I don't see anything odd in there, either, but it would be good to know exactly where it's stopping. If you can paste some of the production code that the problematic step is exercising, that would also be useful. Are iframes or windows involved?

Ok, I added the debug messages and was able to isolate it down to a single line that hangs.

Here is the complete log http://www.speedyshare.com/5UKwq/cucumber.log

In my logs, after using $stdout.puts I get the following debug information:

notice check  notice Backlog was successfully created.
notice check notice_alert notice
notice check selector #alert-space .notice
notice check passed selector check

After that it goes into webkit_debug output and does not seem to ever return back to my Cucumber steps.

The code matching the above notices is as follows:

Then /^(?:|I )should (|not )see the (notice|alert|error|warning) "([^"]+)"$/ do |negation, notice_alert, message|
  $stdout.puts "notice check #{negation} #{notice_alert} #{message}"
  notice_alert = 'error' if notice_alert == 'alert' # errors and alerts are stored in the same .error class
  $stdout.puts "notice check notice_alert #{notice_alert}"
  selector = "#alert-space .#{notice_alert}"
  $stdout.puts "notice check selector #{selector}"
  unless negation.strip == "not" && page.has_no_selector?(selector) # if notice not shown at all allow this to pass if in the negative
    $stdout.puts "notice check passed selector check"
    within(selector) do |content|
      $stdout.puts "notice check within #{selector}"
      if negation.strip == "not"
        page.should_not have_content(message)
        page.should have_content(message)
      $stdout.puts "notice check finished"

So it looks like it's hanging on the line with the value:
within('#alert-space .notice') do |content|

I then thought it might be useful to take a screen shot beforehand as it may help with debugging, and that is when things became odd. I added a new line to the Cucumber steps Then screenshot the page which simply executes screenshot_and_save_page. However, when I ran cucumber the second time round hoping to get a screenshot, I did not see the debug messages notice check*, meaning it hung before it even got to that so probably on the screen shot line. Does this some how mean that Capybara-Webkit is sort of getting stuck on whatever requests comes after the previous Create a new backlog action.

I just don't know where to go from here. Happy to do whatever debugging you want though.

BTW. I wondered if capybara-screenshot was interfering, so I reran the tests without that Gem installed and the same thing happened. I also added a debug line above page.save_page and that gets run, but as soon as page.save_page executes it seems capybara-webkit starts downloading the page..

Received "Body" 
"TimeoutCommand" waiting for load to finish 
Started request to "" 
Received 302 from "" 
1 requests remaining 
4 requests remaining 
Page finished with true 

And just hangs there.

@jferris, oddly I have never actually waited more than around a few minutes once Capybara-Webkit hangs, and always killed the process. This time however I left it running by mistake and when I came back it was running more tests.

Here is the log http://speedy.sh/QGH55/cucumber.log

Look at line 17441 and you will see we get an error: No response received from the server. (Capybara::Webkit::NoResponseError)

Also, if you look at line 17482 you will see that every test afterwards now fails with:
Broken pipe (Errno::EPIPE)

Maybe that will help diagnose the issue?


jferris commented Nov 9, 2012

That pair of errors means that the server crashed after a while. Can you try sending it this command in a before block?

page.driver.browser.timeout = 10

Ok, so far so good, I have been able to run the tests and it's not hung. I will however need to wait for the tests to finish running before I can figure out exactly what's happening, and unfortunately the suite is pretty large (at least 30 minutes). I'll review once done and post the results.

On 9 Nov 2012, at 20:31, Joe Ferris notifications@github.com wrote:

That pair of errors means that the server crashed after a while. Can you try sending it this command in a before block?

page.driver.browser.timeout = 10

Reply to this email directly or view it on GitHub.

Ok, so the tests complete, but I have loads of failing tests because 10s is not quite enough for some of the more in-depth steps. I am not really sure if this is fixing the issue, or just working around the hanging server issue though. I will re-run with a more generous 20s allowance and see if the original test fails or not

Ok, unfortunately even with 20s delay, it runs into problems.

I keep getting errors such as:

  Received "Reset" 
  Started "Reset" 
  Finished "Reset" with response "Success()" 
  Wrote response true "" 
        Connection refused - connect(2) (Errno::ECONNREFUSED)
        /Users/matt/.rvm/rubies/ruby-1.9.3-p286/lib/ruby/1.9.1/net/http.rb:762:in `initialize'
        /Users/matt/.rvm/rubies/ruby-1.9.3-p286/lib/ruby/1.9.1/net/http.rb:762:in `open'
        /Users/matt/.rvm/rubies/ruby-1.9.3-p286/lib/ruby/1.9.1/net/http.rb:762:in `block in connect'
        /Users/matt/.rvm/rubies/ruby-1.9.3-p286/lib/ruby/1.9.1/timeout.rb:54:in `timeout'
        /Users/matt/.rvm/rubies/ruby-1.9.3-p286/lib/ruby/1.9.1/timeout.rb:99:in `timeout'
        /Users/matt/.rvm/rubies/ruby-1.9.3-p286/lib/ruby/1.9.1/net/http.rb:762:in `connect'
        /Users/matt/.rvm/rubies/ruby-1.9.3-p286/lib/ruby/1.9.1/net/http.rb:755:in `do_start'
        /Users/matt/.rvm/rubies/ruby-1.9.3-p286/lib/ruby/1.9.1/net/http.rb:744:in `start'
        /Users/matt/.rvm/rubies/ruby-1.9.3-p286/lib/ruby/1.9.1/net/http.rb:1284:in `request'
        /Users/matt/.rvm/gems/ruby-1.9.3-p286/gems/selenium-webdriver-2.26.0/lib/selenium/webdriver/remote/http/default.rb:83:in `response_for'
        /Users/matt/.rvm/gems/ruby-1.9.3-p286/gems/selenium-webdriver-2.26.0/lib/selenium/webdriver/remote/http/default.rb:39:in `request'
        /Users/matt/.rvm/gems/ruby-1.9.3-p286/gems/selenium-webdriver-2.26.0/lib/selenium/webdriver/remote/http/common.rb:40:in `call'
        /Users/matt/.rvm/gems/ruby-1.9.3-p286/gems/selenium-webdriver-2.26.0/lib/selenium/webdriver/remote/bridge.rb:598:in `raw_execute'
        /Users/matt/.rvm/gems/ruby-1.9.3-p286/gems/selenium-webdriver-2.26.0/lib/selenium/webdriver/remote/bridge.rb:576:in `execute'
        /Users/matt/.rvm/gems/ruby-1.9.3-p286/gems/selenium-webdriver-2.26.0/lib/selenium/webdriver/remote/bridge.rb:350:in `deleteAllCookies'
        /Users/matt/.rvm/gems/ruby-1.9.3-p286/gems/selenium-webdriver-2.26.0/lib/selenium/webdriver/common/options.rb:67:in `delete_all_cookies'
        /Users/matt/.rvm/gems/ruby-1.9.3-p286/gems/capybara-1.1.3/lib/capybara/selenium/driver.rb:81:in `reset!'
        /Users/matt/.rvm/gems/ruby-1.9.3-p286/gems/capybara-1.1.3/lib/capybara/session.rb:70:in `reset!'
        /Users/matt/.rvm/gems/ruby-1.9.3-p286/gems/capybara-1.1.3/lib/capybara/dsl.rb:87:in `block in reset_sessions!'
        /Users/matt/.rvm/gems/ruby-1.9.3-p286/gems/capybara-1.1.3/lib/capybara/dsl.rb:87:in `each'
        /Users/matt/.rvm/gems/ruby-1.9.3-p286/gems/capybara-1.1.3/lib/capybara/dsl.rb:87:in `reset_sessions!'
        /Users/matt/.rvm/gems/ruby-1.9.3-p286/gems/capybara-1.1.3/lib/capybara/cucumber.rb:10:in `After'

jferris commented Nov 9, 2012

That backtrace has selenium-webdriver in it and not capybara-webkit. Are you using selenium for some scenarios?

Yes, it's a mix, but I get the same problem when I run only stories tagged
with capybara webkit. I can send you a log of that if that helps?

Sent from my iPhone

On 9 Nov 2012, at 23:41, Joe Ferris notifications@github.com wrote:

That backtrace has selenium-webdriver in it and not capybara-webkit. Are
you using selenium for some scenarios?

Reply to this email directly or view it on


jferris commented Nov 14, 2012

Yeah, I think that log could be useful. If it's hanging sometimes during scenarios unrelated to capybara-webkit, there's another, unrelated issue at play here. There could also be a bug with capybara-webkit that you're running into, but you're definitely running into a different bug.

No, sorry, I think you've misunderstood.

I ONLY get the issue with capybara-webkit.

However, when I run the complete suite of tests there are some non-capybara-webkit stories in there, so I can see why one might see that the issue is not necessarily capybara-webkit.
However, if I run cucumber tags=@javascript cucumber then filters out all other stories and only runs the capybara-webkit stories and still hangs, meaning it's definitely a capybara-webkit related issue. If I change the driver to selenium and run all the tests with Selenium instead, it works fine.

jnimety commented Nov 16, 2012

I'm running into this as well in a selenium free rspec test suite using 0.13.0. I've set page.driver.browser.timeout=40 and started using webkit_debug to get a backtrace but no additional info gets logged (other than webkit_debug logging "Timeout(40)"). Am I missing additional configs to get the bt?


jferris commented Nov 16, 2012

@jnimety If you're setting the timeout to 40, it should timeout after 40 seconds. I don't know why it isn't. Can you open a separate issue and paste the log, what your test code looks like, and what your production code looks like where it hangs?

I got access to an application that deadlocks during the test suite, so I'm going to try and figure out what the race condition is.

jnimety commented Nov 16, 2012

the timeout is working, I'm just not getting a backtrace like @mattheworiordan. If you have a failing scenario I'll stop debugging, I was just trying to get you more info. Thanks.

I'm experiencing it as well, I think.

It gets stuck in my login step with the following ouput from webkit_debug:

Received "Node.click" 
Started "Node.click" 
Finished "Node.click" with response "Success()" 
Wrote response true "" 
Load started 
Started request to "" 
Received "Find" 
"TimeoutCommand" waiting for load to finish 
Started request to "" 
Received 200 from "" 
1 requests remaining 
Page finished with true

what the step does:

  1. click the login button
  2. HTTP POST with the credentials to /users/sign_in
  3. response is a 302 redirecting to /

But before that, I had a scenario with that same login step that passed with the following output from webkit_debug:

Received "Node.click" 
Started "Node.click" 
Finished "Node.click" with response "Success()" 
Wrote response true "" 
Load started 
Started request to "" 
Received "Find" 
"TimeoutCommand" waiting for load to finish 
Started request to "" 
Received 302 from "" 
1 requests remaining 
Received 200 from "" 
0 requests remaining 
Page finished with true 
Load finished 

When it gets stuck, it looks like the 302 response is not notified back to the client from the webkit server or something like that.

Hope this helps.


jferris commented Nov 30, 2012

@nsocheleau can you show some of the production code that this is testing? I tried reproducing a similar scenario, and my output is different:

Received "Node.click" 
Started "Node.click" 
Finished "Node.click" with response "Success()" 
Wrote response true "" 
Load started 
Started request to "" 
Received 302 from "" 
0 requests remaining 
Started request to "" 
Received "Find" 
"TimeoutCommand" waiting for load to finish 
Received 200 from "" 
0 requests remaining 
Page finished with true 
Load finished 

Note that the 302 always finishes before starting the redirected target, and I never have "1 requests remaining" in the log.

Also, what platform (version of Qt, Linux/Windows/whatever) are you on?


I've reproduced that issue on linux with Qt 4.8.3 and mac with Qt 4.8.0.

I cannot reproduce it consistently though. It happens when I run the full suite of cucumber tests. If I run again the scenario that just hang, it will pass.

Here are the cucumber steps just before it stops for the log above:

  fill_in("Username", :with => email)
  fill_in("Password", :with => password)
  click_button("Sign in")
  page.should have_content("Signed in successfully.")

Here are the list of gems used in my project (the login above is handled by devise):

  • Ascii85 (1.0.1)
  • actionmailer (3.1.3)
  • actionpack (3.1.3)
  • activemodel (3.1.3)
  • activerecord (3.1.3)
  • activerecord-sqlserver-adapter (3.1.7)
  • activeresource (3.1.3)
  • activesupport (3.1.3)
  • acts_as_api (0.4)
  • acts_as_list (0.1.6 ba0962d)
  • addressable (2.2.8)
  • archive-tar-minitar (0.5.2)
  • arel (2.2.3)
  • backup (3.0.24)
  • bcrypt-ruby (3.0.1)
  • builder (3.0.0)
  • bullet (4.2.0)
  • bundler (1.2.1)
  • cancan (1.6.7)
  • capistrano (2.12.0)
  • capistrano-ext (1.2.1)
  • capybara (1.1.2)
  • capybara-webkit (0.12.1)
  • carrierwave (0.5.8)
  • childprocess (0.3.6)
  • chronic (0.6.7)
  • coffee-rails (3.1.1)
  • coffee-script (2.2.0)
  • coffee-script-source (1.3.1)
  • columnize (0.3.6)
  • cucumber (1.1.9)
  • cucumber-rails (1.3.0)
  • daemon_controller (1.0.0)
  • daemons (1.1.8)
  • database_cleaner (0.7.2)
  • devise (2.0.4)
  • devise_invitable (1.0.1)
  • diff-lcs (1.1.3)
  • dotiw (1.1.1)
  • email_spec (1.2.1)
  • erubis (2.7.0)
  • eventmachine (0.12.10)
  • excel_rails (0.3.0)
  • exception_notification (2.6.1)
  • excon (0.9.6)
  • execjs (1.3.1)
  • fabrication (1.3.2)
  • faker (1.0.1)
  • fastthread (1.0.7)
  • fattr (2.2.1)
  • ffi (1.1.5)
  • fog (1.1.2)
  • formatador (0.2.3)
  • formtastic (2.2.0)
  • gherkin (2.9.3)
  • highline (1.6.11)
  • hike (1.2.1)
  • hodel_3000_compliant_logger (0.1.0)
  • i18n (0.6.0)
  • jquery-rails (1.0.19)
  • json (1.7.3)
  • kaminari (0.13.0)
  • launchy (2.1.0)
  • letter_opener (0.0.2)
  • libv8 (
  • libwebsocket (0.1.5)
  • linecache19 (0.5.12)
  • listen (0.4.7)
  • mail (2.3.3)
  • maildir (2.0.0)
  • mailman (0.5.2)
  • memcache-client (1.8.5)
  • metaclass (0.0.1)
  • mime-types (1.18)
  • mini_magick (3.4)
  • mocha (0.11.3)
  • multi_json (1.0.4)
  • net-scp (1.0.4)
  • net-sftp (2.0.5)
  • net-ssh (2.3.0)
  • net-ssh-gateway (1.1.0)
  • nifty-generators (0.4.6)
  • nilify_blanks (1.0.0)
  • nokogiri (1.5.3)
  • oink (0.9.3)
  • open4 (1.3.0)
  • options (2.3.0)
  • orm_adapter (0.0.7)
  • paper_trail (2.6.3)
  • passenger (3.0.12)
  • pdf-inspector (1.0.1)
  • pdf-reader (1.1.0)
  • pg (0.14.1)
  • polyamorous (0.5.0)
  • polyglot (0.3.3)
  • prawn (0.12.0)
  • prawnto_2 (0.2.5)
  • prickle (0.0.6)
  • progress_bar (0.4.0)
  • rack (1.3.6)
  • rack-cache (1.2)
  • rack-mini-profiler (0.1.19)
  • rack-mount (0.8.3)
  • rack-ssl (1.3.2)
  • rack-test (0.6.1)
  • rails (3.1.3)
  • rails-i18n (0.6.3)
  • rails_sql_views (0.8.0)
  • railties (3.1.3)
  • rake (
  • rb-fchange (0.0.5)
  • rb-fsevent (0.9.1)
  • rb-inotify (0.8.8)
  • rdoc (3.12)
  • rspec (2.9.0)
  • rspec-core (2.9.0)
  • rspec-expectations (2.9.1)
  • rspec-mocks (2.9.0)
  • rspec-rails (2.9.0)
  • ruby-debug-base19 (0.11.25)
  • ruby-debug19 (0.11.6)
  • ruby-hmac (0.4.0)
  • ruby-odbc (0.99994)
  • ruby-ole (
  • ruby-prof (0.10.8)
  • ruby-rc4 (0.1.5)
  • ruby_core_source (0.1.5)
  • rubyzip (0.9.9)
  • rvm-capistrano (1.2.7)
  • sass (3.1.15)
  • sass-rails (3.1.5)
  • selenium-webdriver (2.25.0)
  • simplecov (0.6.4)
  • simplecov-html (0.5.3)
  • spreadsheet (0.6.9)
  • sprockets (2.0.4)
  • squeel (1.0.7)
  • subexec (0.2.2)
  • term-ansicolor (1.0.7)
  • therubyracer (0.10.1)
  • thin (1.3.1)
  • thor (0.14.6)
  • tilt (1.3.3)
  • timecop (0.3.5)
  • treetop (1.4.10)
  • trucker (0.5.1)
  • ttfunk (1.0.3)
  • tzinfo (0.3.33)
  • uglifier (1.2.4)
  • uniform_notifier (1.1.0)
  • warden (1.1.1)
  • watu_table_builder (0.3.0)
  • whenever (0.7.3)
  • xpath (0.1.4)
  • xray (1.1)

Let me know if you need any more information.


mhoran commented Dec 4, 2012

If you're feeling lucky, check out pull request #428. I think I tracked down at least one of these issues. Note that the branch requires Capybara 2.0, though the changes could be backported to 0.13 if necessary.

@bryckbost and I had the same issue on a project. #428 changed it from hanging intermittently to failing early and then everything else errors with a Broken pipe (Errno::EPIPE). We're tracking that down now, and will update if we figure anything out.


mhoran commented Dec 7, 2012

@danielmorrison, are you experiencing this with the latest master? I merged in #428 yesterday.

Are the tests reliably failing at the same point, or in different points in the test suite? Do you get any output when the tests fail, for example "pure virtual method called terminate called without an active exception"?

Could you provide us with more information about your environment? Are you running on Linux or OS X? We don't have a reliable way to analyze core dumps at the moment, but I'm looking into adding a crash reporter to make this possible. If you're comfortable with gdb, you could try getting a backtrace from the core dump on your own.

Yep, we updated this afternoon. Same results on Travis-ci and OS X. We're see what we can grab, but it probably won't be today.

Looks like one test will fail with `No response received from the server. (Capybara::Webkit::NoResponseError)`` and then everything after will get a Broken Pipe. Nothing obvious why the initial error hits, but I'll keep looking!

Still don't have a "why" but found a workaround: If I toss in a sleep before the lines that give the No response error, it runs fine.


mhoran commented Dec 10, 2012

@danielmorrison, could you run the offending test with the webkit_debug driver and paste the output? That should help us get an idea about what's happening under the hood.

Are you on OS X? It'd be awesome if you could get a backtrace. You can set OS X and Linux to allow core dumps with ulimit -c unlimited. When capybara-webkit crashes, it should dump a core to /cores/core.PID, where PID is the PID of webkit_server, or to the current directory on Linux. Finally, running gdb bin/webkit_server <core> will get you in a GDB session, from which bt will return the current backtrace.


mhoran commented Dec 11, 2012

No luck, same issue. I haven't had time to do anything more than try :webkit_debug yet. Sorry!


mhoran commented Dec 11, 2012

Thanks for testing. You're likely hitting a different bug now, as I am able to reproduce the original deadlock with capybara-webkit 0.13.0, but not with master.

Could you paste the :webkit_debug output of the failing scenario? We could at least see what the driver thinks is happening when it crashes.

mhoran added a commit to mhoran/capybara-webkit that referenced this issue Dec 12, 2012


mhoran commented Dec 19, 2012

@danielmorrison, could you try out bca84f9? If you continue to experience segfaults, please follow the instructions in #380.

Hello @mhoran
Sorry, it took me a while to get back to you. I tried your pull request, I actually used the master as I understand you merged it. The issue is fixed for me. No more hanging.

Hi @mhoran, sorry it has taken me so long to confirm as well, but so far so good. Unfortunately the upgrade to Capybara 2 has broken lots of things, so I have not yet had a chance to run the complete suite in full. As soon as I do, I will confirm here that the issue is fixed.

Downgrading capybara-webkit from 0.13.0 to 0.12.1 seemed to solve this for me.

This was in conjunction with capybara 1.1.2


mhoran commented Dec 21, 2012

@barmstrong, I'd recommend you try out the latest master, which fixes a number of segfaults in capybara-webkit. Note that master requires Capybara 2.0.

coolo commented Dec 21, 2012

An unrelated question: how about a prerelease for easier testing capybara-webkit master? I'm looking daily for a -webkit release that goes with 2.0 ;(

larryh commented Dec 24, 2012

I experienced the same thing that 'barmstrong' did, i.e. when I tried capybara-webkit 0.13.0 random cucumber tests would hang with a NoResponseError. This did not happen when I use Selenium or when I use capybara-webkit 0.12.1.

I know you're interested in moving forward, but I thought relaying this might give you some insight as to what is going on.

I am using capybara 1.1.3. I tried upgrading to capybara 2.0 but that broke a LOT of my cucumber tests, so I backed down to 1.1.3 for now.

Thanks for working on this. I know it must be incredibly complex and (dare I say) a royal pain in the %$#.


mhoran commented Dec 24, 2012

Thanks for the report. Your issue has hopefully been fixed on master. We don't plan to backport these fixes to Capybara 1.x, and instead encourage users to upgrade to Capybara 2.0.

Bumping to master fixed this for me. 👍


mhoran commented Jan 4, 2013

@mattheworiordan, how is your Capybara 2.0 upgrade going? We just released capybara-webkit 0.14.0 which should resolve this issue.

taavo commented Jan 4, 2013

Just wanted to say thanks for wrestling with this, mhoran. 0.13 was a bumpy ride for me, with regular but inconsistent crashes. So far, 0.14 is beautiful--and my suite's running about 30% faster for some reason. Many thanks.

@mhoran, apologies for the delay, I got about half way through and then got pulled into an urgent project. As soon as I have some downtime, I'll complete that upgrade and give you an update. However, so far it looks good, not had any problems.

larryh commented Jan 6, 2013

Like taavo, I would also like to say "thanks" to mhoran and the rest of the crew at thoughtbot for working - and following up - on this. And to mattheworiordan for the effort he has put into this problem.

I just upgraded capybara from 1.1.3 to 2.0.2 and capybara-webkit from 0.12.1 to 0.14.0. So far it seems pretty good, but lot of my tests are being skipped because of "ambiguous matches" introduced in Capy 2.0 - which means it's hard for me to experience server timeouts because a lot of my tests aren't being run.

I will tackle that problem and return to this thread to let you (and future visitors) know how the new version is doing.

Once again, thanks for your efforts!

@mhoran, I am just dropping you a quick line to say I've still not had time to finish the migration to Capybara 2. Te suite is very large, so is taking a long time, and I have to do this in the background as we have various priorities. I thank you again for your effort, and apologise I cannot throw more time at it myself right now to give you the feedback you deserve.

larryh commented Feb 6, 2013

Hello again. Just wanted to (finally) check back in and report that I'm using 0.14.1 and it works like a charm! Thanks a lot to everyone who works on this gem!

The capybara-webkit 1.0 randomly hang on entire suite for me as well.

explicit use of Thin handler helped. Added to env.rb:

Capybara.server do |app, port|
  require 'rack/handler/thin'
  Rack::Handler::Thin.run(app, :Port => port)

betelgeuse commented Aug 8, 2013

@DimaSamodurov does your upgrade to capybara-webkit 1.0 also upgrade your capybara over major versions? Thin support was dropped from capybara a while back jnicklas/capybara#920

I use capybara 2.1. This is currently a recent version, not a master though. They removed default Thin handler, but not prohibited to use it in general. I don't have intention to suggest a specific server for tests. I just shared my context of the issue. May be differences of handling connections by Webrick and Thin could point to the real source of the issue.


mhoran commented Aug 8, 2013

Just a warning, support for Thin was dropped due to the fact that it is not thread safe. You may run in to some exciting new issues by using Thin as your Rack server.

If possible, could you let us know if this is a new issue in 1.0, or if it is present in 0.14.2 as well? Note that 0.14.2 is not compatible with Capybara 2.1 so I understand if this is not possible.

I have been using 0.14.2 with capybara 2.0.2 patched with several fixes and back-ports from 2.1 for several months and did not get any hangups. I tried Thin as a workaround to be able to upgrade to Capybara 2,1, Capybara-wekit 1.0, Qt4.8. We don't use threads intensively but thanks for the reminder, I'll keep it i mind. I don't have clear idea how to debug this particular issue, because it happens only in a batch but i would experiment..


jferris commented Nov 9, 2013

I haven't seen this issue in a long time, and the consistent reports have ceased to come in, so I'm going to consider the original issue resolved.

If capybara-webkit starts hanging on you, please open a new issue with as much information as possible, including debug logs.

@jferris jferris closed this Nov 9, 2013

If it is the same problem I was having, then it's an issue with the Webkit implementation that Qt 4 uses on OSX. The solution is to upgrade to Qt 5 which uses a newer version that doesn't throw these kinds of errors when trying to play MP4 videos, for instance.

See this blog post for details about the problem and solution: http://magnemg.tumblr.com/post/113251336220/how-to-solve-a-capybara-webkit-and-video-js

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment