Hangs on FindCss

[nritholtz]

I'm trying to figure out exactly what's going on here in my test case, but I figured you guys might know what's going on quicker than I will.

Here is the gist for the webkit debug. Essentially there's two cucumber scenarios ran one after another, and the second scenario is getting stuck on a find().set and just hangs. I had to manually kill the process.

I was able to reproduce it multiple times when running the two scenarios in same session, but when running individually it works fine. Unfortunately it's proprietary code, so I can't post the reproducible test that I am running.

[nritholtz]

I didn't realize that the default timeout for Capybara Webkit is -1, which I assume means never timeout. When I set the timeout to 30, the same log as the gist occurred, but it then failed with:

Wrote response false "{"class":"TimeoutError","message":"Request timed out after 30 second(s)"}"
    Given I have signed into the test Express portal as a USD prepaid user        # features/test/step_definitions/shared_steps.rb:1
      2015-06-18T12:32:37-04:00:    Portal User: auto1434599772
      Request timed out after 30 second(s) (Capybara::Webkit::TimeoutError)

[nritholtz]

I realized the issue probably is that a Load Started was made after the driver.reset! was called by the driver.

In my test, the last action for the first scenario is a click, which for my purposes doesn't wait for the resulting page to load (since I didn't really care about the resulting page, as much as a backend process that would trigger). The next page does a javascript based form.submit() to PayPal on $(document).ready. This I assume isn't covered by the driver.reset!, since the request isn't made until after the page is loaded, so it's out of scope of requests that the driver can cancel.

As far as I can see, the only way to work around this issue is to make sure the form.submit() page is finished with its submit before finishing the scenario, or make a driver.reset! call as a Before hook call. I'm open to any suggestions on driver side since there may be scenarios that people run into my same issue, but I can't think of anything offhand.

[jferris]

We shouldn't be making requests after reset! is called. We know about requests which start after the page loads, and we abort them when reset! is called starting in 1.5.1.

What triggers that last request there? Is it from a setTimeout function?

[nritholtz]

@jferris, if you are talking about page.driver.browser.timeout, then no, because I didn't even know it would be necessary to use until this issue came up.

When I did try using it, it did timeout as mentioned above.

Let's call the 3 pages: submit, form, and paypal.

I think the best way for me to explain it is if you see some of my capybara code:

 first("#paypal_amount").set @input_value
 first("#paypal_submit").click

That's the end of the test. So it's on submit page and that click leads to form page, that has a hidden form with values for submission, in addition to JavaScript on the page:

  $( document ).ready(function(){
    $("#paypal-form").submit();
  })

This will submit the form and take the user to the paypal page.

I assumed that since the driver.reset! was called on the submit page, it sees the click request is in progress, so it ultimately waits for the form page to finish loading. Which it does, but then the JavaScript on the form page fires on the $(document).ready and starts a new Load after the driver.reset! already finished.

[jferris]

Sorry, by setTimeout, I meant in JavaScript.

When the driver gets a reset command, it actually deletes all of the web page instances, so I'm surprised that they continue to make requests after a reset. We may need to tell the pages to stop processing (or just navigate to a blank page) before deleting them.

[nritholtz]

Yeah, there's definitely no setTimeout in the JavaScript, from what I can see, unless it's being included as part of some other library.

After further inspection, the first request after the Reset() finished was the form submission to the PayPal URL, which confirms my suspicion. It's the JavaScript that I posted in my previous comment that is being called from the form page, even though the Reset() had finished.

[nritholtz]

I have a reproducible case that I will upload in a sec.

[nritholtz]

Hey @jferris, I pushed a test case nritholtz@8cff5d3 but unfortunately I can't get it fail on every run, maybe you can see what could be added to make it consistently fail.

However, running DEBUG=true bundle exec rspec spec/driver_spec.rb:243 would intermittently hang with what I think is the issue I'm having.

[jferris]

Thanks a bunch! I'll try to take a look at this tomorrow.

[nritholtz]

Hey @jferris, I know it's been super busy, but any chance of taking a look at this?

[twalpole]

Closing due to age - We can reopen if this is still an issue with current releases.