Timeout when loading a URL containing a # hash / fragment identifier

[pete-otaqui]

In a step definition, this:

visit('/page#do-some-javascript')

completely fails to load anything, and doesn't even seem to time out (I got bored after > 5 minutes). Swapping in the :selenium driver makes the page work as expected. When I did finally kill the test run, I got the rather unhelpful error:

undefined method strip' for nil:NilClass (NoMethodError)`

I'm using cucumber 0.10.2, capybara-webkit 0.3.0 and capybara 0.4.1.2 on Ubuntu, but not too sure where to look for any more logging information.

[cblavier]

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

[cpytel]

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

[pete-otaqui]

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?

[cpytel]

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

[carhartl]

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.

[chris]

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.

[christiannelson]

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?

[svyatogor]

I can reproduce this on

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

No warnings, just takes forever and never ends.

[christiannelson]

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

[cpytel]

This may be related to #212

[jferris]

@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.

[mkocher]

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

[pete-otaqui]

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

[drewB]

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

[jfelchner]

@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?

[pete-otaqui]

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

[SanderMander]

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