redirect (sometimes) goes to a blank page. (cached 302's???) #841
Comments
|
Also having this issue! Exactly the same - Completed 302 Found, and then a GET for the next page. Capybara somehow executing the expectations on the next page. |
|
Hi @patrick99e99, I was trying to update my gem versions and perhaps I'm running your same problem. But it returns a blank page like <html><head></head><body></body></html>I have tracked the version of capybara-webkit that this error first appears.
I have
and ...
@patrick99e99, could you try capybara-webkit 1.5.2 on your setup to see if the issue is only from 1.6.0. I think this could be of value to someone trying to fix it. And also, I have changed this in my setup. (As you said that a cached GET is the suspect, I think should be important to show these fragments also). config/routes.rb MyAppName::Application.routes.draw do
devise_for :users, :controllers => { :sessions => "users/sessions" }
# It seems devise always send GET requests.
# The destroy session would be a DELETE request.
# Making GET possible for production sessions#destroy seems
# to be a security failure.
# So we make a GET route available _only_ on tests.
if Rails.env.test?
devise_scope :user do
get '/users/sign_out' => 'devise/sessions#destroy'
end
end
# ...
endconfig/initializers/devise.rb Devise.setup do |config|
#...
# The default HTTP method used to sign out a resource. Default is :delete.
config.sign_out_via = :delete
config.sign_out_via = :get if Rails.env.test?
# ...
end |
|
@patrick99e99 Since you are using Rails, in your Rails.application.configure do
#... all your other stuffs
config.middleware.delete Rack::ETag
endYou'll see in your test debug output that you are getting a 304 and things fall apart from there. We were getting the same issue and 304 was causing capybara to give us a response body exactly as you posted above. |
I have the simplest of simple as far as tests go:
... This fails, claiming it was unable to find the selector 'form'. This is an intermittent failure (my favorite kind) which happens every few spec runs. I found that if I use the seed of a failing test run, it will fail each and every time which means somehow it has something to do with previous browser state. I am assuming that for some reason, capybara-webkit sometimes gets hung up on 302 redirects, as the sign out link goes to /sign_out and that redirects to /sign_in. Since I can reproduce this with the same random seed, I was able to do screenshot prior to failure and I see:
http://tinyurl.com/pm3tlfm
It is a blank page... Nothing there.. I tried setting my default max timeout is set to something ridiculous like 30 seconds... It never shows anything. However, my rails test log shows during this failing spec:
So it is rendering the page.. Capybara is somehow just not getting the response.
.... Also since I can reproduce this with the seed, I spent over an hour debugging / troubleshooting by going in and commenting out previous specs to isolate what about the current test order causes this failure. I finally found there is one spec, if I comment it out, this sign out spec no longer fails... And guess what that spec is doing? Clicking cancel on a modal which signs out the user. So I am suspecting the action of visiting /sign_out is somehow getting cached in capybara-webkit, and the second time it gets that it just goes to that "blank page" without actually redirecting
This is what my capybara-webkit debug shows during the failure:
The text was updated successfully, but these errors were encountered: