Skip to content
This repository has been archived by the owner on Mar 3, 2020. It is now read-only.

Unable to load URL: http://127.0.0.1:52548/fredrik #109

Closed
fbjork opened this issue Jul 13, 2011 · 45 comments
Closed

Unable to load URL: http://127.0.0.1:52548/fredrik #109

fbjork opened this issue Jul 13, 2011 · 45 comments

Comments

@fbjork
Copy link

fbjork commented Jul 13, 2011

I have the following in my Gemfile:
gem 'capybara', '1.0.0'
gem 'capybara-webkit', '1.0.0.beta4'

and this in my spec_helper.rb:
Capybara.javascript_driver = :webkit

running in a Ruby 1.9.2/Rails 3.0.9 app and get this when I run my JS RSpec acceptance tests:

Unable to load URL: http://127.0.0.1:52548/fredrik

I don't see the webkit driver starting. I've installed the non debug Cocoa OSX dmg. Any ideas?

@jferris
Copy link
Member

jferris commented Jul 14, 2011

The WebKit driver starts silently - it's headless. Can you check your application logs to see if there's anything interesting? That error is raised if capybara-webkit can't load the page for any reason, but sometimes it's hard to know why.

@fbjork
Copy link
Author

fbjork commented Jul 14, 2011

Ok. Does capybara-webkit work in a threadsafe environment with Fibers in Ruby 1.9.2?

@jferris
Copy link
Member

jferris commented Jul 14, 2011

I haven't ever tried fibers, so I'm not sure. If you can isolate your
problem to fibers, please let me know.

On Thu, Jul 14, 2011 at 11:01 AM, fbjork <
reply@reply.github.com>wrote:

Ok. Does capybara-webkit work in a threadsafe environment with Fibers in
Ruby 1.9.2?

Reply to this email directly or view it on GitHub:

#109 (comment)

@fbjork
Copy link
Author

fbjork commented Jul 14, 2011

Unfortunately I don't see anything in the logs. I remember having these issues with Cucumber and Selenium in a Fiber app, so this is probably the issue.

@azolotov
Copy link

I've had a similar issue. All tests would use 127.0.0.1, but some of them failed with messages such as

Unable to load URL: http://127.0.0.1:51186/canvas (Capybara::Driver::Webkit::WebkitInvalidResponseError)

test.log didn't reveal anything helpful.

This only happened with webkit, using

  • capybara (1.0.1)
  • capybara-webkit (0.6.0)
  • rails 3.1rc5
  • ruby 1.9.2

While my issue is probably different from yours, I suggest that you check where and how you redirect the visitor.

After wasting a whole day on trying to solve this, we found that the problem was with a redirect inside of one of the controllers:

before_filter :redirect_user, :only => :new

def redirect_user
  unless current_user.profile
    redirect_to new_canvas_profile_path
  else
    redirect_to canvas_quiz_path
  end
end

Without that filter all the tests pass again :)

@jferris
Copy link
Member

jferris commented Oct 1, 2011

We added a :webkit_debug driver that prints more information that could be useful to us. Can you attach the output from the debug driver?

@croaky
Copy link
Contributor

croaky commented Oct 2, 2011

I saw this error as well after I added Thin to my Gemfile.

Upgrading to capybara-webkit 0.7.1 and capybara 1.1.1 fixed the issue.

@micahalles
Copy link

I'm running into a similar issue. It looks like it may be caused by a Browser#reset! call capybara is making at the end of each spec while a redirect or request is still being processed.

Backtrace

Capybara::Driver::Webkit::WebkitInvalidResponseError:
  Unable to load URL: http://127.0.0.1:59583/projects
# /home/ci/work/7bccc6267d45de0b/vendor/bundler/ruby/1.9.1/gems/capybara-webkit-0.7.2/lib/capybara/driver/webkit/browser.rb:176:in `check'
# /home/ci/work/7bccc6267d45de0b/vendor/bundler/ruby/1.9.1/gems/capybara-webkit-0.7.2/lib/capybara/driver/webkit/browser.rb:72:in `command'
# /home/ci/work/7bccc6267d45de0b/vendor/bundler/ruby/1.9.1/gems/capybara-webkit-0.7.2/lib/capybara/driver/webkit/browser.rb:32:in `reset!'
# /home/ci/work/7bccc6267d45de0b/vendor/bundler/ruby/1.9.1/gems/capybara-webkit-0.7.2/lib/capybara/driver/webkit.rb:88:in `reset!'
# /home/ci/work/7bccc6267d45de0b/vendor/bundler/ruby/1.9.1/gems/capybara-1.1.1/lib/capybara/session.rb:70:in `reset!'
# /home/ci/work/7bccc6267d45de0b/vendor/bundler/ruby/1.9.1/gems/capybara-1.1.1/lib/capybara/dsl.rb:87:in `block in reset_sessions!'
# /home/ci/work/7bccc6267d45de0b/vendor/bundler/ruby/1.9.1/gems/capybara-1.1.1/lib/capybara/dsl.rb:87:in `each'
# /home/ci/work/7bccc6267d45de0b/vendor/bundler/ruby/1.9.1/gems/capybara-1.1.1/lib/capybara/dsl.rb:87:in `reset_sessions!'
# /home/ci/work/7bccc6267d45de0b/vendor/bundler/ruby/1.9.1/gems/capybara-1.1.1/lib/capybara/rspec.rb:16:in `block (2 levels) in <top (required)>'
# /home/ci/work/7bccc6267d45de0b/vendor/bundler/ruby/1.9.1/gems/rspec-core-2.6.4/lib/rspec/core/example_group.rb:324:in `instance_eval'
# /home/ci/work/7bccc6267d45de0b/vendor/bundler/ruby/1.9.1/gems/rspec-core-2.6.4/lib/rspec/core/example_group.rb:324:in `instance_eval_with_rescue'
# /home/ci/work/7bccc6267d45de0b/vendor/bundler/ruby/1.9.1/gems/rspec-core-2.6.4/lib/rspec/core/hooks.rb:45:in `run_in'
# /home/ci/work/7bccc6267d45de0b/vendor/bundler/ruby/1.9.1/gems/rspec-core-2.6.4/lib/rspec/core/hooks.rb:80:in `block in run_all'
# /home/ci/work/7bccc6267d45de0b/vendor/bundler/ruby/1.9.1/gems/rspec-core-2.6.4/lib/rspec/core/hooks.rb:80:in `each'
# /home/ci/work/7bccc6267d45de0b/vendor/bundler/ruby/1.9.1/gems/rspec-core-2.6.4/lib/rspec/core/hooks.rb:80:in `run_all'
# /home/ci/work/7bccc6267d45de0b/vendor/bundler/ruby/1.9.1/gems/rspec-core-2.6.4/lib/rspec/core/hooks.rb:126:in `run_hook_filtered'
# /home/ci/work/7bccc6267d45de0b/vendor/bundler/ruby/1.9.1/gems/rspec-core-2.6.4/lib/rspec/core/example_group.rb:226:in `eval_after_eachs'
# /home/ci/work/7bccc6267d45de0b/vendor/bundler/ruby/1.9.1/gems/rspec-core-2.6.4/lib/rspec/core/example.rb:149:in `run_after_each'
# /home/ci/work/7bccc6267d45de0b/vendor/bundler/ruby/1.9.1/gems/rspec-core-2.6.4/lib/rspec/core/example.rb:54:in `block in run'
# /home/ci/work/7bccc6267d45de0b/vendor/bundler/ruby/1.9.1/gems/rspec-core-2.6.4/lib/rspec/core/example.rb:107:in `with_around_hooks'
# /home/ci/work/7bccc6267d45de0b/vendor/bundler/ruby/1.9.1/gems/rspec-core-2.6.4/lib/rspec/core/example.rb:45:in `run'
# /home/ci/work/7bccc6267d45de0b/vendor/bundler/ruby/1.9.1/gems/rspec-core-2.6.4/lib/rspec/core/example_group.rb:294:in `block in run_examples'
# /home/ci/work/7bccc6267d45de0b/vendor/bundler/ruby/1.9.1/gems/rspec-core-2.6.4/lib/rspec/core/example_group.rb:290:in `map'
# /home/ci/work/7bccc6267d45de0b/vendor/bundler/ruby/1.9.1/gems/rspec-core-2.6.4/lib/rspec/core/example_group.rb:290:in `run_examples'
# /home/ci/work/7bccc6267d45de0b/vendor/bundler/ruby/1.9.1/gems/rspec-core-2.6.4/lib/rspec/core/example_group.rb:262:in `run'
# /home/ci/work/7bccc6267d45de0b/vendor/bundler/ruby/1.9.1/gems/rspec-core-2.6.4/lib/rspec/core/example_group.rb:263:in `block in run'
# /home/ci/work/7bccc6267d45de0b/vendor/bundler/ruby/1.9.1/gems/rspec-core-2.6.4/lib/rspec/core/example_group.rb:263:in `map'
# /home/ci/work/7bccc6267d45de0b/vendor/bundler/ruby/1.9.1/gems/rspec-core-2.6.4/lib/rspec/core/example_group.rb:263:in `run'
# /home/ci/work/7bccc6267d45de0b/vendor/bundler/ruby/1.9.1/gems/rspec-core-2.6.4/lib/rspec/core/command_line.rb:24:in `block (2 levels) in run'
# /home/ci/work/7bccc6267d45de0b/vendor/bundler/ruby/1.9.1/gems/rspec-core-2.6.4/lib/rspec/core/command_line.rb:24:in `map'
# /home/ci/work/7bccc6267d45de0b/vendor/bundler/ruby/1.9.1/gems/rspec-core-2.6.4/lib/rspec/core/command_line.rb:24:in `block in run'
# /home/ci/work/7bccc6267d45de0b/vendor/bundler/ruby/1.9.1/gems/rspec-core-2.6.4/lib/rspec/core/reporter.rb:12:in `report'
# /home/ci/work/7bccc6267d45de0b/vendor/bundler/ruby/1.9.1/gems/rspec-core-2.6.4/lib/rspec/core/command_line.rb:21:in `run'
# /home/ci/work/7bccc6267d45de0b/vendor/bundler/ruby/1.9.1/gems/rspec-core-2.6.4/lib/rspec/core/runner.rb:80:in `run_in_process'
# /home/ci/work/7bccc6267d45de0b/vendor/bundler/ruby/1.9.1/gems/rspec-core-2.6.4/lib/rspec/core/runner.rb:69:in `run'
# /home/ci/work/7bccc6267d45de0b/vendor/bundler/ruby/1.9.1/gems/rspec-core-2.6.4/lib/rspec/core/runner.rb:11:in `block in autorun'

Debug driver output

>> Find
>> 1
>> 493
>> .//a[./@href][(((./@id = 'Upload' or normalize-space(string(.)) = 'Upload') or ./@title = 'Upload') or .//img[./@alt = 'Upload'])] | .//input[./@type = 'submit' or ./@type = 'image' or ./@type = 'button'][((./@id = 'Upload' or ./@value = 'Upload') or ./@title = 'Upload')] | .//input[./@type = 'image'][./@alt = 'Upload'] | .//button[(((./@id = 'Upload' or ./@value = 'Upload') or normalize-space(string(.)) = 'Upload') or ./@title = 'Upload')] | .//input[./@type = 'image'][./@alt = 'Upload']
<< ok
<< 1
<< 2
>> Node
>> 2
>> 7
>> visible
>> 1
>> 2
<< ok
<< 4
<< true
>> Node
>> 2
>> 7
>> visible
>> 1
>> 2
<< ok
<< 4
<< true
>> Node
>> 2
>> 5
>> click
>> 1
>> 2
<< ok
<< 0
<< 
>> Reset
>> 0
<< failure
<< 51
<< Unable to load URL: http://127.0.0.1:59583/projects

@jferris
Copy link
Member

jferris commented Nov 1, 2011

We can issue a user "Stop" request before resetting to see if that solves
the issue.

@micahalles
Copy link

Actually, I was just able to reproduce this behavior with a "Find" command as well. I even inserted a ~60 sleep between the "Node.click" and "Find" calls, and still received the same failure. It seemed like that failure response was queued / held up, and then being sent after the next command, regardless of what it was:

>> click
>> 1
>> 2
<< ok
<< 0
<< 
>> Find
>> 1
>> 7
>> .//body
<< failure
<< 51
<< Unable to load URL: http://127.0.0.1:33271/projects
>> Reset
>> 0
<< ok
<< 0
<< 

After further investigation I realized our http://127.0.0.1:59583/projects request was a redirect after a POST within an iframe to accomplish async file uploads with remotipart 1.0.0. Once I changed the action handling the POST to respond with a small JSON response instead of redirecting, our tests completed successfully.

Our team was only seeing this issue on our CI machine:

ubuntu 2.6.35-30-generic
Qt 4.7.0
single core

We did not encounter the problem on our multicore OS X laptops with Qt 4.7.4

I can revert our fix to reproduce the issue if you think of anything you'd like me to try.

@vitobotta
Copy link

Hi, I am getting the same "Unable to load URL" errors after posting a form to update a resource. Is there any update on this? Thanks

@tvdeyen
Copy link

tvdeyen commented Jan 26, 2012

Same for me. It started after upgrading my bundle to:

rspec 2.8.0
capybara-webkit 0.8.0
capybara 1.1.2

This error does not shows up everytime I ran my specs, only sometimes.

@vitobotta
Copy link

Hi tvdeyen,

Weird, for me it happened each time.

I am not sure of what "fixed" the issue for me in the end as it kinda disappeared with the combination of gems and perhaps some changes in the code that I had made.

Sorry not to be of much help. I wish I knew for sure what caused that problem.

Cheers
Vito

@tammersaleh
Copy link

Seeing this as well. Also intermittent, and nothing interesting to report in the logs.

@buger
Copy link

buger commented Feb 25, 2012

Same error :(

capybara-webkit 0.10.0

I'm using Backbone, i'm clicking on link that changes location #hash and should trigger Backbone router.

Here is my Teamcity log: https://gist.github.com/1910910

Also i dig a little bit to make more debug info, and also show info coming to command function, and added 'result' variable to exception: 'raise WebkitInvalidResponseError, read_response + " " + result

@jferris
Copy link
Member

jferris commented Feb 27, 2012

We're working on ways to improve the feedback here, but in the meantime, here are a couple of suggestions:

  • Try tailing your test.log for a Rails app; frequently there are exceptions that get swallowed by the background server but end up in the log.
  • Try switching your driver to :webkit_debug. It prints all the commands it's sending to the webkit_server, which sometimes provides insight into what went wrong.

@buger
Copy link

buger commented Feb 28, 2012

I found one of cases when it failing: https://gist.github.com/1926473

It shows this error if one of the iframes on page is failed to load.

Hope it helps!

@jferris
Copy link
Member

jferris commented Mar 2, 2012

@buger thanks, that should help us fix at least one of the issues here. We'll look into that.

@jferris
Copy link
Member

jferris commented Mar 16, 2012

@buger tried out your gist today, but it seems like it's failing because that's a bad domain. It fails because it can't load that page, which seems correct to me. If you change to load "www.something.com" it works.

@buger
Copy link

buger commented Mar 16, 2012

@jferris exactly, it fail all suite, because one of the iframes on the page is failed to load. I don't think it's normal situation.

It should not fire error. If twitter or facebook widget and etc. will down, than all pages that include it will raise this error in test case.

@jferris
Copy link
Member

jferris commented Mar 19, 2012

@buger if an iframe fails to load on the page, that means the page didn't load successfully. If you have iframes with unreliable or unimportant content, I recommend you fake out those services during tests.

@jc00ke
Copy link
Contributor

jc00ke commented Apr 17, 2012

I just ran into this now.

 >> Visit
 >> 1
 >> 18
 >> http://127.0.0.1:/
 << failure
 << 37
 << Unable to load URL: http://127.0.0.1/


     Failure/Error: visit "/"
     Capybara::Driver::Webkit::WebkitInvalidResponseError:
       Unable to load URL: http://127.0.0.1/

Notice no port number. capybara 1.1.2 & capybara-webkit 0.11.0

[Update] Forgot to mention, this is a Sinatra app. And what I neglected to do was set

Capybara.app = MySinatraApp.new

Now I don't see this issue anymore.

@pacovell
Copy link

pacovell commented May 7, 2012

I see this issue when I changed Rails' config.action_dispatch.ignore_accept_header = true and re-ran our working test suite.

Here are some observations:
1 - The tests don't fail when I run only the specific scenario; they fail only when I run a whole feature file
2 - The tests don't fail when I use webkit_debug
3 - I don't have any iframes on these pages
4 - The test.log shows successful rendering of the page

If the only difference between webkit and webkit_debug is extra printouts, then I suspect some kind of timing-dependent error. Is that assumption correct?

[Update]
I realize this may make me look crazy, but while attempting to further narrow down the problem, it stopped occurring. I believe the 'solution' is related to putting :webkit_debug in as the driver selection, running with success, and then replacing with :webkit, the tests are now running correctly. Is it possible there is some kind of cache associated that is getting cleared with a driver change?

@tvdeyen
Copy link

tvdeyen commented May 7, 2012

Same for me:

1 - The tests don't fail when I run only the specific scenario; they fail only when I run a whole feature file
3 - I don't have any iframes on these pages
4 - The test.log shows successful rendering of the page

I can confirm that this might be a timing issue.

@schnittchen
Copy link

I observe pretty much the same as pacovell.

In my case, I was able to narrow down to one example running.
There is an rspec option (don't know right now which one) that executes all examples when a modified spec file has been successfully run. Due to the use of :focus => true, both times the same one example gets executed, first it passes, then it fails with the above WebkitInvalidResponseError.

The example passes when I use :webkit_debug instead of :webkit driver. It passes when I insert a single "nil" statement at the beginning of the example.

There is an iframe on the page being tested, but it is not interacted with.

test.log looks good.

So, inserting nil made the bug disappear, so did insertion of any debugging trick I tried. Since a nil statement shouldn't change timings significantly, I suspect a bug somewhere in a C extension that is triggered by some byte positions being different at times. If true, this is pretty impossible to track down.

@schnittchen
Copy link

Folks,

I THINK I solved my problem (you never know that when it's a heisenbug), so I'd like to let you know because other people might hit upon here and read what their problem might be about.

I used page.execute_script to simulate interaction with an iframe (already a workaround). Could be that execute_script does not wait for the script to complete as evalutate_script does (which I couldn't use either), so the next DOM interaction happened too early.

I solved that by using another execute_script to modify the DOM (add class to <body>) to have something I could then wait for with page.should have_css('body.signal-class')

Hope that helps!

@tvdeyen
Copy link

tvdeyen commented Jun 11, 2012

Any updates on this? I still have this issues and they are very annoying.
So, what is planned to fix this?
Where can we help?

@lucaspiller
Copy link

I'm also getting what appears to be this issue. I am using remotipart, and although the iframe request returns a 200 response it appears red in the Chrome developer tab which I guess is also considered a failure by this driver (it is fine with Selenium however). Here is the response:

Cache-Control:max-age=0, private, must-revalidate
Connection:close
Content-Type:text/html; charset=utf-8
Date:Fri, 22 Jun 2012 15:34:30 GMT
ETag:"52dd32d9108e1be54f6882c1b4efef34"
Set-Cookie:_hst_session=*snip*; domain=.hst.localhost; path=/; HttpOnly
Status:200 OK
X-Rack-Cache:invalidate, pass
X-Request-Id:e9b855eb554c24647e6af598e7fef9eb
X-Runtime:5.319091
X-UA-Compatible:IE=Edge

<textarea data-type="text/javascript" response-code="200">

*snip javascript*

</textarea>

What is the textarea stuff about - that isn't mentioned anywhere in my views?

Here is the development log:

Started POST "/host/property/documents" for 127.0.0.1 at 2012-06-22 16:34:25 +0100
Processing by Host::Property::DocumentsController#create as JS
  Parameters: {"document"=> {"file"=>#<ActionDispatch::Http::UploadedFile:0x007fc6e7d370d8 @original_filename="Homestays-EI-Presentation.png", @content_type="image/png", @headers="Content-Disposition: form-data; name=\"document[file]\"; filename=\"Homestays-EI-Presentation.png\"\r\nContent-Type: image/png\r\n", @tempfile=#<File:/tmp/RackMultipart20120622-4412-1fa3wtm>>, "upload_id"=>"no-flash", "document_type_id"=>"proof_of_address", "name"=>"logo", "expiry_date"=>""}, "utf8"=>"✓", "authenticity_token"=>"*snip*", "remotipart_submitted"=>"true", "X-Requested-With"=>"IFrame", "X-Http-Accept"=>"text/javascript, application/javascript, application/ecmascript, application/x-ecmascript, */*; q=0.01"}
  Flash success is "Your document has been successfully uploaded."
Completed 200 OK in 5277ms (Views: 1666.0ms | ActiveRecord: 4.8ms)

Edit: The spec works fine if I don't use remotipart.

@tvdeyen
Copy link

tvdeyen commented Jun 22, 2012

I finally have the solution: https://github.com/jonleighton/poltergeist

Uses phantomjs, is a easy dropin replacement, works out of the box. No more problems.

And one can even run the specs on travis-ci!!

Byebye capybara-webit.

@sarahmei
Copy link

sarahmei commented Aug 7, 2012

I'm also seeing the issue when an iframe on the page 500s. I can see your point @jferris that if an iframe fails to load, the page fails to load. I think the error message could be improved.

The message I get is:
Capybara::Driver::Webkit::WebkitInvalidResponseError: Unable to load URL: [URL for the main page from 2 redirects ago]

It would be more helpful if it said something like "iframe #foo failed to load" :)

@jferris
Copy link
Member

jferris commented Aug 7, 2012

@sarahmei can you try out the master branch? I've made some changes to the way it expects pages to load that may improve that specific scenario.

@sarahmei
Copy link

sarahmei commented Aug 7, 2012

@jferris Thanks! I am now getting:

Capybara::Webkit::InvalidResponseError: Unable to load URL: [URL for main page 2 redirects ago] because of error loading [long iframe URL]: SSL handshake failed

That is much easier to debug. Much appreciated.

@Ragmaanir
Copy link

The same error occurs in our application. I think i narrowed it down a bit:

We have a login-overlay-iframe which is inserted via JS when one clicks the 'sign in' link.
Our test code looks kinda like this (TestUnit):

def sign_in_via_form_as user
    visit root_path
    click_link "Anmelden"

    within_frame("iframe") do
      fill_in 'user_email', :with => user.email
      fill_in 'user_password', :with => user.password
      click_button 'Anmelden'
    end
end

should '...' do
  user = create(:user)
  sign_in_via_form_as user
  assert page...
end

We then always received this error:

Capybara::Driver::Webkit::WebkitInvalidResponseError: Unable to load URL: http://localhost:3001/users/sign_in

To make sure that the error is not caused by a 500 http status code or so, i started a test server:

rails s -e test -p 3001

And changed the test_helperto not start a server:

Capybara.run_server = false

But there were no errors shown in the log (only status 200 and 302).

When logging in via the iframe, the server returns a redirect to the iframe which then displays the root_path. Then a javascript that is contained in the root_pathpage is triggered. This script checks if the current page is embedded in an iframe and if so sets the location of the top window to the location of the iframe and removes the iframe. It looks like this:

if(top != window) {
    top.location.href = window.location.href;
    $(top.document).find('#overlay').remove();
  }

It seems that this redirect process makes the within_framemethod raise that exception:

def within_frame(frame_id_or_index)
      browser.frame_focus(frame_id_or_index)
      begin
        yield
      ensure
        browser.frame_focus
      end
    end

It seems to be caused by the browser.frame_focus in the ensure-block which probably is invoked during the redirection-process. So i modified the test case:

def sign_in_via_form_as user
    visit root_path
    click_link "Anmelden"

    #within_frame("iframe") do
      page.driver.browser.frame_focus('iframe')
      fill_in 'user_email', :with => user.email
      fill_in 'user_password', :with => user.password
      click_button 'Anmelden'
      sleep 2
    #end
end

Basically leaving out the second call to browser.frame_focus. Also i had to add a sleep because the redirection process took so long. I could not use page.wait_until{ page.has_css? ... } because it also threw the error.

I hope this might help people who struggle with a similar issue.
Btw: capybara-webkit version 0.12.1

@kirillivanov
Copy link

forse_ssl can be the reason as well...

@larryh
Copy link

larryh commented Oct 12, 2012

Has any work been done on this? It seems numerous solutions have been proposed... but nothing definitive or resolved.

Here is my sad story:

We are using capybara-webkit to run our RSpec tests and everything passes on my own, relatively slow, 32-bit laptop - including the specs using javascript.

However, the same specs consistently fail when running the javascript tests on a much faster 64-bit machine for the same reason mentioned at the beginning of this issue:
Capybara::Driver::Webkit::WebkitInvalidResponseError: Unable to load URL: http://127.0.0.1:33826/sign_in

My situation is the same as mentioned by "pacovell" and others in this thread:

  1. When I run all tests, the "sign-in" (javescript) ones fail.
  2. When I run a failing test by itself, it passes.

The behavior is consistent, i.e. it does not come and go as others have mentioned. The fact that running all => "fail" and running one => "pass", coupled with the fact that all tests always pass on my slower laptop leads me to believe - as others have surmised in this thread - that this is a timing issue.

I have been searching the web and trying different things for a couple of days:

  1. Sprinkled 'sleep 5' statements around the offending statements.
  2. Specified "Capybara.javascript_driver = :webkit_degug" in my "spec_helper.rb" file.
  3. Started up the test server from the command line and went to the sign-in page to make sure the page itself wasn't the culprit. It wasn't.

And regarding #2, I didn't see any special output in either the console or the test.log file. Did I miss something?

I'm at my wit's end on this - does anyone have any suggestions?

Thanks,
Larry

@jferris
Copy link
Member

jferris commented Oct 12, 2012

There are a number of fixes for loading issues in master, but we're running into difficult bugs with Qt 4.8 that have stalled us for the moment. I hope to take another look at those issues soon, and then hopefully we can revisit loading issues after this release.

@larryh
Copy link

larryh commented Oct 13, 2012

Okay, Joe. Thanks for taking the time to let me know what's going on - I appreciate it. (And all of the work you guys do on all of the gems you provide!)

@pcreux
Copy link
Contributor

pcreux commented Oct 19, 2012

I solved this issue by removing thin from my Gemfile. (thanks @croaky for the hint).

@jferris Could capybara-webkit warn us if it detects thin?

@jferris
Copy link
Member

jferris commented Oct 19, 2012

@pcreux I may do that. I've been meaning to look into the thin issues, because I've used thin and capybara-webkit together every project I work on, and it hasn't been an issue. The Qt 4.8 issues are the current priority, though.

@larryh
Copy link

larryh commented Oct 22, 2012

We're using unicorn instead of thin, so while removing thin might solve some problems I don't think you can say thin is the culprit.

@greyblake
Copy link

Have same issue. Spec failures are intermittent.
polergeist driver works fine. Thanks @tvdeyen.

@calleluks
Copy link

Is this still an issue in the latest version of capybara-webkit?

@larryh
Copy link

larryh commented May 29, 2015

Don't think so; I haven't seen this problem in years.

@calleluks
Copy link

Great! I'll close this. If anyone is still having these issues, please re-open this issue.

@pdswan
Copy link

pdswan commented Aug 26, 2015

[Update]
Although I could not observe any issues in the debug output of curl nor in the developer console on Chrome, Safari, or Firefox config.ignore_ssl_errors resulted in the tests passing.

Still having this issue w/ filepicker.

Error:

Unable to load URL: http://127.0.0.1:9887/ because of error loading https://www.filepicker.io/dialog/comm_iframe/: Unknown error (Capybara::Webkit::InvalidResponseError)

Manifestation:
Manifests every time when run on a local development machine OSX 10.10.5 (14F27) but does not manifest consistently on CI. Working on trying to diagnose differences in those machines.

The URL we navigate to does result in a 302, so we may have some version of the redirect issue mentioned above. I'll confirm whether this manifests if we navigate directly to the resulting URL.

Dependency Versions:

qt 5.4.2 (installed via brew)

Gem Versions:

capybara 2.4.4
capybara-webkit 1.6.0

Debug Logs

Wrote response true ""
Received "Visit(http://127.0.0.1:9887/)"
Started "Visit(http://127.0.0.1:9887/)"
Load started
"Visit(http://127.0.0.1:9887/)" started page load
Started request to "http://127.0.0.1:9887/"
Finished "Visit(http://127.0.0.1:9887/)" with response "Success()"
Started request to "http://127.0.0.1:9887/some/application/path"
Received 302 from "http://127.0.0.1:9887/"
Started request to "http://127.0.0.1:9887/assets/application.css"
Started request to "http://127.0.0.1:9887/some/other.css"
Started request to "http://127.0.0.1:9887/assets/application.js"
Started request to "https://fast.fonts.net/jsapi/projectId.js"
Received 200 from "http://127.0.0.1:9887/some/application/path"
Received 200 from "http://127.0.0.1:9887/assets/application.js"
Received 200 from "http://127.0.0.1:9887/assets/application.css"
Received 404 from "http://127.0.0.1:9887/some/other.css"
Received 200 from "https://fast.fonts.net/jsapi/projectId.js"
Started request to "http://127.0.0.1:9887/assets/image.png"
Started request to "https://www.filepicker.io/dialog/comm_iframe/"
Started request to "http://127.0.0.1:9887/user/generated/image.png"
Received 200 from "http://127.0.0.1:9887/assets/image.png"
Received 200 from "http://127.0.0.1:9887/user/generated/image.png"
Started request to "http://fast.fonts.net/t/1.css?apiType=js&projectid=projectId"
Received 200 from "http://fast.fonts.net/t/1.css?apiType=js&projectid=projectId"
Received 0 from "https://www.filepicker.io/dialog/comm_iframe/"
Page finished with false
Load finished
Page load from command finished
Wrote response false "{"class":"InvalidResponseError","message":"Unable to load URL: http://127.0.0.1:9887/ because of error loading https://www.filepicker.io/dialog/comm_iframe/: Unknown error"}"

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests