#226 ✓wontfix
barunio

not waiting for page load with selenium

Reported by barunio | April 20th, 2009 @ 03:22 PM | in 0.4.2

in my app, this fails:


def login_as(user, password)
  visit new_session_path
  fill_in "username", :with  => user.username
  fill_in "password", :with => password
  click_button('Go')
  response.body.should =~ /Signed in as #{user.username}/
end

but this works:


def login_as(user, password)
  visit new_session_path
  fill_in "username", :with  => user.username
  fill_in "password", :with => password
  click_button('Go')
  selenium.wait_for_page_to_load(5)
  response.body.should =~ /Signed in as #{user.username}/
end

webrat isn't appropriately waiting for a new page to load before executing the next step. i am using version 0.4.4

just for reference, this is related to an earlier email sent on the rspec mailing list: http://www.nabble.com/-cucumber-...

Comments and changes to this ticket

  • gaffo

    gaffo April 22nd, 2009 @ 12:41 PM

    did you update your selenium client?

  • gaffo

    gaffo May 7th, 2009 @ 07:00 PM

    • Tag changed from selenium, wait_for to selenium, stale, wait_for
  • gaffo

    gaffo May 7th, 2009 @ 07:00 PM

    • State changed from “new” to “open”
  • Scott Johnson
  • gaffo

    gaffo June 3rd, 2009 @ 10:10 AM

    Scott,
    Which version of selenium client do you have installed? gem list | grep selenium-client

    Thanks

  • Scott Johnson

    Scott Johnson June 4th, 2009 @ 06:31 PM

    I have selenium-client 1.2.15, the latest on rubyforge.

  • gaffo

    gaffo June 4th, 2009 @ 07:23 PM

    I've noticed this a bit as well. I have some timing issues when I try to get response.body.

    The issue is that selenium takes a tiny little bit (which grows as the machine gets slower) to update the response.body after each invocation.

    There are a few options here, I'm currently doing:

    automate do
    selenium.wait_for_page_to_load end

    before tests that are failing for this reason.

    What we would like to do is move some of these asserts into javascript and have selenium execute them. This would remove the timeout. Then you could do assert_xpath / etc.

    I'm open to suggestions on what we can do to make it wait better but don't really know how to solve it other than that at the moment.

  • Scott Johnson

    Scott Johnson June 4th, 2009 @ 08:04 PM

    It looks like selenium-client has something to deal with this (from README.markdown):

    • click 'the_button_id', :wait_for => :page

    But I can't see where webrat uses this :wait_for option anywhere.

    Perhaps in SeleniumSession#click_button, the user could pass in :wait_for in the options hash, and webrat will pass it on to selenium.click?

  • gaffo

    gaffo June 4th, 2009 @ 08:07 PM

    def click_button(button_text_or_regexp = nil, options = {})

      if button_text_or_regexp.is_a?(Hash) && options == {}
        pattern, options = nil, button_text_or_regexp
      elsif button_text_or_regexp
        pattern = adjust_if_regexp(button_text_or_regexp)
      end
      pattern ||= '*'
      locator = "button=#{pattern}"
    
      selenium.wait_for_element locator, :timeout_in_seconds => 5
      selenium.click locator
    end
    

    it waits until it can find teh locator or for 5 seconds. or it fails.

    We're actually discussing some of this stuff in the irc channel.

  • Scott Johnson

    Scott Johnson June 4th, 2009 @ 08:29 PM

    The selenium.click :wait_for option waits after the click.

  • gaffo

    gaffo June 5th, 2009 @ 03:07 PM

    Yes. I thought you were railing on the response.body.should =~ /Signed in as #{user.username}/

    right?

    If so, then it will click, wait, and then go on. Correct?

  • Scott Johnson

    Scott Johnson June 5th, 2009 @ 04:31 PM

    I think I understand the waiting a little better. Webrat doesn't use the selenium-client click :wait_for option because it waits whenever the next thing comes up. That is, if there's a response.body.should, then it waits for that to match before failing.

    There are a few holes in this strategy. For example, current_url doesn't ever wait, and gives me stale results sometimes. (This was the failing case I was seeing; not response.body. Sorry for the confusion.)

    Also, response.body.should_not will sit there and wait 5 seconds to make sure whatever should not be there doesn't happen to show up. That is, the passing case involves always waiting 5 seconds. This seems broken.

    I wonder if Webrat is trying to be too clever about the waiting. After all, it's not the matching that requires waiting, but the clicking. If you told Selenium what to wait for after each click (which is how Selenium seems to be designed to be used) then matching would never require waiting.

    This seems much more robust to me. The downside? Somehow you have to tell Selenium what to wait for each click.

  • Amos King

    Amos King June 8th, 2009 @ 11:34 AM

    Asserting that something is not on the page seems like a bad idea anyway. If I say that "Bob" is not there, and "bob" is on the page then it still won't fail. At least saying something is there will fail if it isn't exact. Saying it is not there is far more dependent on the exact format showing up to fail.

  • Scott Johnson

    Scott Johnson June 8th, 2009 @ 12:00 PM

    The context here is testing that login is required for a particular page. Without login, I should_not see the text. After login, I should see the text. Using a cucumber template I test both sides.

    I think it is a robust way to test what I need to test, but I'm open to suggestions.

  • gaffo

    gaffo June 8th, 2009 @ 12:06 PM

    • State changed from “open” to “wontfix”
    • Milestone set to 0.4.2

    I think in this case we have to leave it up to the developer to put the right wait in. If it's an ajax link, you need to wait_for_ajax right after the click. If it's a normal link, wait_for_page.

    I can't really think of anything that is more clever that won't fail or slow things down in a different fashion for all of the reasons listed above.

    I'm going to close this ticket as won't fix unless we can come up with a better option. Sorry, and thanks for the feedback.

Please Sign in or create a free account to add a new ticket.

With your very own profile, you can contribute to projects, track your activity, watch tickets, receive and update tickets through your email and much more.

New-ticket Create new ticket

Create your profile

Help contribute to this project by taking a few moments to create your personal profile. Create your profile ยป

Ruby Acceptance Testing for Web applications.

Shared Ticket Bins

Referenced by

Pages