Random failure: Capybara::Webkit::InvalidResponseError: 'undefined' is not an object #550

Closed
marcgg opened this Issue Jul 23, 2013 · 30 comments

Comments

Projects
None yet

marcgg commented Jul 23, 2013

Hello,

Running 1.0.0 with ruby 2.0.0-p247 & qt-4.8.5 I am getting random Capybara::Webkit::InvalidResponseError every once in a while. Let's say I run my tests 10 times in a row it might happen twice on 2 different tests.

I tried on various machines and it seems to happen more frequently on the less powerful setups, but even very recent macbook pros run into the issue.

I've spent some time trying to figure out what could be wrong in my code, but there isn't anything out of the ordinary, so I am not sure anymore how to go about this so I figured I'd bring this up here.

This issue seemed to be linked to our recent upgrade to Ruby 2.0, but I could be wrong since - like I said - it's very random.

Thanks

Contributor

miks commented Jul 25, 2013

+1, same problem for me

Same here, I thought It was CircleCI, but It happens locally.... sometimes

gustly commented Aug 5, 2013

+1, we have seen this as well

grimsock commented Aug 7, 2013

The same problem here:
Capybara::Webkit::InvalidResponseError:
'undefined' is not an object

+1, happening on two different finds sporadically.

Collaborator

mhoran commented Aug 9, 2013

I spent some time looking into this today, and it looks like at least one source of the issue may be navigating away from a page between the time Node#invoke checks whether an element is still present on the page before interacting with it. There is a very slight chance of this possibility, but should it happen, it would lead to hard to reproduce issues resulting in undefined is not an object errors. Perhaps one thing we could do is provide a better error message in such a case so that it's easier to debug.

Owner

jferris commented Aug 9, 2013

Yeah, I think the best thing we can do is divide InvalidResponseError into three:

  • Raise InvocationFailed when Node#invoke fails.
  • Raise JavascriptError when we know there was a failure in user Javascript (ie, execute_script and evaluate_script).
  • Raise InvalidResponseError when a command actually fails for an unknown reason.

We can also add some more defensive code and logging/exceptions around node handling if we think there are race conditions there.

+1, I'm getting this as well (although only on CircleCi, haven't seen it locally yet). Same config as OP. Anyone have a workaround yet?

👍 seems to only occur on our CI server

I was seeing this issue when I used the following line immediately after a click action which redirected the browser to another page. Even

find('.some_class_name', text: 'Some Text') 

After changing this to an xpath, it works 100% of the time:

find(:xpath,'//h1[contains(@class,"some_class_name") and contains(text(),"Some Text")]') 

I thought it might be a timing issue so before trying the xpath, I tried changing the capybara default timeout value; however, this had no effect. The issue was only resolved when I switched to the xpath selector.

Collaborator

mhoran commented Aug 21, 2013

Interesting. We introduced native CSS selectors as part of capybara-webkit 1.0.0 (and upstream Capybara 2.1). It's possible that there's something with native CSS selectors that's causing an issue with our node interactions. Thanks for the additional details.

marcgg commented Aug 21, 2013

My test failing was indeed using css selectors like @tmertens'. I just replaced them with xpath selectors. I'll update the ticket later on to let you know if the random failures disappeared or not.

marcgg commented Aug 22, 2013

Alright, I replaced CSS selectors with xpath selectors and after a day I'm still getting the exact same error on my CI. Also some tests never fail randomly but they use css selectors... so I guess that's not the issue.

You are still getting the same exact error? I started seeing a timeout
error from the CI after I switched to xpaths but didn't see the
InvalidResponseError anymore.
On Aug 22, 2013 3:25 AM, "Marc G Gauthier" notifications@github.com wrote:

Alright I replaced CSS selectors with xpath selectors, and after a day I'm
still getting the exact same error on my CI. Also some tests never fail
randomly but they use css selectors... so I guess that's not the issue.


Reply to this email directly or view it on GitHubhttps://github.com/thoughtbot/capybara-webkit/issues/550#issuecomment-23074892
.

marcgg commented Aug 22, 2013

@tmertens Yes I'm getting the exact same error. It took ~20 runs to see one appear, but it's identical: Capybara::Webkit::InvalidResponseError: 'undefined' is not an object

+1 we're seeing this issue to. It happens much more frequently on our CI, too (we are using Tddium). But, I've seen the same failure running locally as well. In both cases they are intermittent and seem to be pretty random, though it occurs more often in some tests than others.

I've found that every test I've applied tmertens genius solution to now passes consistently. All the failures occurred after a page navigation (generally triggered by an event within a modal dialog). Kinda sucks to have to modify the tests, but at least there's a way out.

I'm also noticing this issue on Rails 4.0.0 w/ Ruby 2.0.0p247. The context in which it's failing involves clicking a "save" button, which invokes an ajax call, and then a Turbolinks.visit once the ajax request completes. I get the following error:

Failure/Error: page.should have_content I18n.t('documents.create.success')
Capybara::Webkit::InvalidResponseError:
'undefined' is not an object

I'm having the same problem, locally and in jenkins, with the following backtrace:

Failures:

  1. Landing pages landing pages with different campaign layouts with a campaign layout CPL it should behave like invalid data for cpl campaigns when I visit the landing page and fill form with invalid data it should behave like error messages visit landing page with errors should show the flash error message
    Failure/Error: Unable to find matching line from backtrace
    Capybara::Driver::Webkit::WebkitNoResponseError:
    No response received from the server.
    Shared Example Group: "error messages" called from ./spec/support/shared/landing_examples.rb:166

    /var/lib/jenkins/.rbenv/versions/1.9.3-p448/lib/ruby/gems/1.9.1/gems/capybara-webkit-0.12.1/lib/capybara/driver/webkit/browser.rb:136:in `check'

    /var/lib/jenkins/.rbenv/versions/1.9.3-p448/lib/ruby/gems/1.9.1/gems/capybara-webkit-0.12.1/lib/capybara/driver/webkit/browser.rb:87:in`command'

    /var/lib/jenkins/.rbenv/versions/1.9.3-p448/lib/ruby/gems/1.9.1/gems/capybara-webkit-0.12.1/lib/capybara/driver/webkit/browser.rb:22:in `reset!'

    /var/lib/jenkins/.rbenv/versions/1.9.3-p448/lib/ruby/gems/1.9.1/gems/capybara-webkit-0.12.1/lib/capybara/driver/webkit.rb:108:in`reset!'

    /var/lib/jenkins/.rbenv/versions/1.9.3-p448/lib/ruby/gems/1.9.1/gems/capybara-1.1.4/lib/capybara/session.rb:70:in `reset!'

    /var/lib/jenkins/.rbenv/versions/1.9.3-p448/lib/ruby/gems/1.9.1/gems/capybara-1.1.4/lib/capybara/dsl.rb:87:in`block in reset_sessions!'

    /var/lib/jenkins/.rbenv/versions/1.9.3-p448/lib/ruby/gems/1.9.1/gems/capybara-1.1.4/lib/capybara/dsl.rb:87:in `each'

    /var/lib/jenkins/.rbenv/versions/1.9.3-p448/lib/ruby/gems/1.9.1/gems/capybara-1.1.4/lib/capybara/dsl.rb:87:in`reset_sessions!'

    /var/lib/jenkins/.rbenv/versions/1.9.3-p448/lib/ruby/gems/1.9.1/gems/capybara-1.1.4/lib/capybara/rspec.rb:16:in `block (2 levels) in <top (required)>'

Finished in 13 minutes 11 seconds
364 examples, 1 failure

Failed examples:

rspec ./spec/support/shared/landing_examples.rb:85 # Landing pages landing pages with different campaign layouts with a campaign layout CPL it should behave like invalid data for cpl campaigns when I visit the landing page and fill form with invalid data it should behave like error messages visit landing page with errors should show the flash error message
Coverage report generated for RSpec to /var/lib/jenkins/jobs/wuakitv-wuaki_web-dc6e96a874de9b7a1946b7fdc5e149fd/workspace/coverage. 5582 / 6511 LOC (85.73%) covered.
script/cibuild: line 39: kill: /var/lib/jenkins/cerberus_pid_web1381135980: arguments must be process or job IDs
Build step 'Execute shell' marked build as failure
Finished: FAILURE

We're getting this issue too. At first we thought it was only during our parallel features, but it turns out it just shows up more frequently then.

In our case the problem was in our code. We were making calls to urls out of the testing environment (google analytics) and then the driver was lost. Check if this could be also your case.

kianw commented Oct 17, 2013

+1 We're seeing it intermittently when using page.should have_content to test for a page that is displayed after a page with a Javascript-enabled progress bar completes. The previous page refreshes itself every 500ms until a job finishes, and then moves on to the page with the content we're expecting. Increasing the timeout doesn't seem to help.

@ghost

ghost commented Oct 18, 2013

+1 We're getting the same issue but very intermittent.

wbyoung commented Oct 24, 2013

I ended up here via a search after experiencing a somewhat related problem. For anyone who may have something similar, here's what was causing the failure for me.

I have a test that does the following:

  page.within_window page.driver.browser.window_handles.last do
    expect(page).to have_content "some content"
  end

My app is doing the following during this test:

  • Open new browser window
  • Perform AJAX request
  • Update the opened window's location based on info from the AJAX response

My have_content assertion expecting all of these steps have completed. I'm guessing what is happening is that Capybara Webikit considers the change of the location to somehow invalidate the window/page that it's focused on. I was able to fix my tests by doing the following before the page.within_window from above:

  find('form:not(.processing)')

And updating the javascript to add the processing class to the form while it waits for the AJAX response. I hope this may be helpful to someone else who ends up on this issue.

Using find(:xpath, ... as described in this comment #550 (comment) worked for us. Thanks @tmertens !!

As already described in other comments it happens when a normal find is executed before some javascript code changes the page by changing window.location.

mtkd commented Nov 9, 2013

Seen a similar issue related to a window.location.

I use this wait_for_ajax method before the page.find or page.has_css?:

    def wait_for_ajax
      Timeout.timeout(Capybara.default_wait_time) do
        loop do
          active = page.evaluate_script('jQuery.active')
          break if active == 0
        end
      end
    end

Fyi, we get this a bit when triggering a page change in javascript. Most often, it's on an assertion similar to:

page.should have_content "Success!"

It is a little surprising to me that page could be the 'undefined' when capybara-webkit calls invoke, but I guess page is no different than any other node?

toothrot commented Dec 2, 2013

Bit of an update here. After stripping out most page.should have_content around pageloads in our application, we have managed to eliminate this failure that appears to be a super (un)lucky timing issue. Replacing with selecting an element that is only on the new page solves the issue.

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

Thanks @redbar0n. I'll close this issue due to the long time of inactivity. Feel free to re-open it if you're still experiencing these issues.

@wied03 wied03 added a commit to wied03/opal-rails that referenced this issue Aug 17, 2015

@wied03 wied03 Given weirdness in travis w/ webkit + qt 4.x (see thoughtbot/capybara…
…-webkit#550 (comment)), trying selenium/firefox
8cc6e47

@wied03 wied03 added a commit to wied03/opal-rails that referenced this issue Aug 17, 2015

@wied03 wied03 Travis failed when local succeeded
Given weirdness in travis w/ webkit + qt 4.x (see thoughtbot/capybara-webkit#550 (comment)), trying selenium/firefox
92eb04e
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment