Vapir::Firefox not waiting properly in a very niche situation

[rmcauley]

Trying Vapir out, and in my test case, it's not waiting for sub-frames
to load before the wait() function finishes, just the same as Watir.

I've found out that it's a very peculiar situation that I haven't been
able to successfully sequester into a nice test-case outside of our in-
house web app. However, here are the steps that are happening that
stop it from working as I see it.

The pseudocode for the whole setup is:

<frameset>
<frame id="1" />
<frame id="2"><a id="link">link</a>
<iframe id="3"><a id="link2">link2</a></iframe>
</frame>
</frameset>

The iframe is broken out into another HTML file, but for brevity the
pseudocode skips that. There's a lot of AJAX and Javascript going on
inside iframe#3, so once in a while I need to hit up a#link. a#link
in effect reloads the page as *exactly the same setup* right down to
the same iframe#3 URL. Firefox appears to do this reload very
quickly; obviously using a lot of cache in the process. Sometimes the
universal browser throbber doesn't appear to animate. However, Watir/
Vapir doesn't wait at all marches on ahead regardless of the state of
the page. (while Firefox is still rendering from cache, Ruby has
already thrown an exception and quit)

Short of implementing a lot of wait_for()s that would be extremely
tricky since browser.frame(:id, "3").exists? is not an available
method, is there a workaround? Can the Watir/Vapir devs think of a
way to improve the wait() code for this situation?

It's admittedly hard to reproduce, but we've gotten really far with
Watir/Vapir on IE and it's working just fine over there, and I don't
feel like resetting everything and moving over to a competing solution
like Selenium after we've done so much dev against this.

I'm going to try experimenting with Firefox's cache settings to see if
there's any way to mitigate this problem.

- Rob

[Ethan]

dang, I thought I had fixed this sort of thing, in firefox anyway. I updated firefox's #wait method to keep track of active connections that a page made and wait until they were all complete, which should theoretically make it work for ajax. Is this a problem in both IE and FF, or just FF? 

in case the javascript stuff that's going on isn't waiting for a server, though, I don't think there is any way to determine if javascript is running / wait for it. 

Vapir does have a slightly nicer way to deal with waiting for an element, with an improved Waiter class (in my opinion anyway). Instead of something like 

div=ie.div(:id, 'foo')

Watir::Waiter.wait_until { div.exists? }

you can do: 

div=::Waiter.try_for(8) { ie.div?(:id, foo) }

the #div? method is like the usual #div, but method returns nil if the div doesn't exist, and #try_for returns the result of the block, so you can do the whole thing in one line. the 8 is the number of seconds to wait. 

I'm also thinking of adding another container method that will automatically wait. Something like 

ie.wait_div(:id, 'foo') 

which will return that div once it exists, or raise a timeout exception if it doesn't exist after some interval. That seems like something that would be increasingly useful, with all the ajax coming into prevalence these days. 

-Ethan