Timeout when loading a URL containing a # hash / fragment identifier about capybara-webkit HOT 17 CLOSED

This visit(campaign_path(campaign,anchor: 'twitter')) dosen't do anything if browser already was launched before and this is a second call of 'visit' function.
E.g.

before { visit(dashboard_path) }
it 'bla bla bla', js: true do
  visit(campaign_path(campaign,anchor: 'twitter')) # this will be ignored if before called
  expect(page).to have_content 'Greetings'
end

from capybara-webkit.

Same issue for me. It's a show-stopper when testing applications built on sammy.js with a lot of hash urls.

from capybara-webkit.

I just pushed version 0.4.1 which includes 66a6145 which fixes this issue.

from capybara-webkit.

Hi,

thanks for the effort, but it doesn't seem to work for me. I'm interested to see that in your patch you seem to calling the same thing twice:

QUrl requestedUrl = QUrl(arguments[0]);
page()->currentFrame()->setUrl(QUrl(requestedUrl));
if(requestedUrl.hasFragment()) {
  // workaround for https://bugs.webkit.org/show_bug.cgi?id=32723
  page()->currentFrame()->setUrl(QUrl(requestedUrl));
}

Does that really fix the problem? Shouldn't you be setting the fragment in the second call, rather than the URL again?

from capybara-webkit.

The fix worked for me, and if you read the bug linked in the comment, you'll see that thats what the workaround was, unless I'm misreading something.

Sorry it doesn't seem to be fixed for you. Can you provide a test case to illustrate where it doesn't work?

On Jun 3, 2011, at 9:43 AM, pete-otaqui wrote:

Hi,

thanks for the effort, but it doesn't seem to work for me. I'm interested to see that in your patch you seem to calling the same thing twice:

QUrl requestedUrl = QUrl(arguments[0]);
page()->currentFrame()->setUrl(QUrl(requestedUrl));
if(requestedUrl.hasFragment()) {
 // workaround for https://bugs.webkit.org/show_bug.cgi?id=32723
 page()->currentFrame()->setUrl(QUrl(requestedUrl));
}

Does that really fix the problem? Shouldn't you be setting the fragment in the second call, rather than the URL again?

Reply to this email directly or view it on GitHub:
#52 (comment)

Chad Pytel, Founder and CEO
thoughtbot, inc.
t: 617-482-1300 x113
f: 866-217-5992
http://www.thoughtbot.com
http://www.twitter.com/thoughtbot

from capybara-webkit.

Doesn't work for me either. I'm can try to create a test case, but my test is rather simple anyway, for what it's worth, posting it here already:

require 'spec_helper'

describe "Rewrite rules", :driver => :webkit do
  it "rewrites /videos to hashbang form" do
    visit '/videos/1'
    current_path.should == '/'
    current_url.should match(%r(/#!/videos/1$))
  end

  it "rewrites /people to hashbang form" do
    pending "subsequent examples crashing capybara-webkit"
    visit '/people/1'
    current_path.should == '/'
    current_url.should match(%r(/#!/people/1$))
  end

  it "does not rewrite /subscriptions" do
    pending "subsequent examples crashing capybara-webkit"
    visit '/subscriptions'
    current_path.should == '/subscriptions'
  end
end

Just tested with capybara 1.0.0, capybara-webkit 0.4.1 (forked to use capybara 1.0). Important to know here is that the first test passes and only subsequent ones are giving me said error. Not entirely sure if it's the same issue.

from capybara-webkit.

I'm seeing this now with the latest gems as of today:

Ruby 1.9.2p180
Rails 3.0.4
cucumber 1.1.0
cucumber-rails 1.1.1
capybara 1.1.1
capybara-webkit 0.7.2

I have (for example):

visit "app#cities/San+Francisco"

(or any URL that has a hash/anchor in it). Our output shows that it goes to that page, but then just hangs - the scenario never terminates, and webkit_server is still running.

from capybara-webkit.

Same here. Using capybara-webkit 0.7.2 to test a backbone application, calling visit to any url that includes a # hangs forever and ever. Can we reopen this issue?

from capybara-webkit.

I can reproduce this on

• capybara (1.1.1)
• capybara-webkit (0.7.2)

No warnings, just takes forever and never ends.

from capybara-webkit.

@cpytel can you reopen this? Do you have an recommendations for helping diagnose the problem?

from capybara-webkit.

This may be related to #212

from capybara-webkit.

@pete-otaqui can you try this again with the latest master? We've merged some fixes related to URL changes that may fix your problem.

from capybara-webkit.

I just ran into this issue, pointed at master and it started working.

from capybara-webkit.

hi @jferris, will give it a try, although I'm on a different distro these days!

from capybara-webkit.

I was having this issue and can confirm that when I updated to 0.12 the problem was fixed.

from capybara-webkit.

@pete-otaqui looks like this may be working for others. If you're not going to have time to verify, want to close it out?

from capybara-webkit.

Closing because it seems to be ok for people, and I am not geared up to check this any more!

from capybara-webkit.