yeah its pretty hard to give an answer that might actually help without some code to look at.
When the form is submitted what happens? do the fields become disabled? is there some sort of spinner to show that the forms is actually doing something? why does the form take so long to do a post? Are users really going to wait longer than 30-60 seconds for the page to load? I suggest watching what is happening in firebug's net tab and see what is running when you submit the form. What OS are you on? what version of Watir-Webdriver? Because that might make a difference also. On Wed, Jun 13, 2012 at 4:16 AM, Chuck van der Linden <[email protected]>wrote: > Ben is there a public version of the page that you could point people to, > along with a brief bit of watir code so that we can see the behavior for > ourselves. > > Also while you say this is not an ajax page, the behavior you describe is > somewhat typical of ajax pages (even if it might just be caused by a lot of > clientside java executing right after the last bit of the page is loaded > from the server) so perhaps one of these methods might help? > > https://github.com/watir/watir-webdriver/wiki/AJAX-and-waiting-for-elements > > > > On Wednesday, June 6, 2012 9:33:06 AM UTC-7, Ben Armstrong wrote: >> >> I have a problem closely resembling the one posted here, and I do not see >> any satisfactory answers in this thread: >> >> http://stackoverflow.com/**questions/10404789/watir-** >> webdriver-how-to-force-the-**click-method-to-wait-for-the-** >> page-to-load-comp<http://stackoverflow.com/questions/10404789/watir-webdriver-how-to-force-the-click-method-to-wait-for-the-page-to-load-comp> >> >> That is, I was using watir (1.6.2) and changed to watir-webdriver (0.6.1) >> after which, all my rspecs performing button.click actions no longer wait >> until the next page is drawn (not an AJAX page). These buttons have >> Javascript onclick handlers to ensure the button isn't pressed twice, but >> aside from that behave like ordinary form submissions. >> >> I have worked around the problem in one of two ways, neither of which are >> acceptable in the long term. I'm seeking a better general solution: >> >> 1. If the click just causes the default form submit action, bypass >> the click and trigger a submit on the form. This is unacceptable because >> 'submit this form' is not a user action, and I want to test only what the >> user is doing and what the user can see as a result. >> 2. Otherwise (in the case where which button on the form changes how >> the script receiving the click behaves), follow the click with a >> hard-coded >> wait of, say, 20 seconds. This is unacceptable because the more tests we >> add, the more these delays compound, and are fragile in the face of other >> demands being placed on the system at the time, besides. >> >> All of the non-solutions I've seen so far (including all answers to the >> post linked above) relate to waiting for some predictable change of the >> contents of the page. But not only do the page changes vary from one case >> to the next, but I can't even identify some element that I could always >> count on as a "sentinel" to determine that "yes, we've arrived at the next >> page". Some button clicks just return me back to the page I was on, looking >> very much like it did before the click. What I, like the poster of the >> above stackexchange article, had hoped would be the case is to directly >> observe that a new page is being visited and wait for it to finish loading, >> period. No nasty tricks required, like having the application inject a >> counter into the page so we can check it before and after the click to see >> if it changed. Does watir-webdriver not provide such a facility? It seemed >> to one of my colleagues I shared this problem with to be a staggering >> design flaw in watir-webdriver, and while I wanted to defend the package, >> as I am quite enamored already of the possibilities it promises, I had no >> satisfactory answer. >> >> Sadly, we'll remain shackled to a less flexible, more cumbersome, and >> more costly proprietary solution unless I can sell my team on >> watir-webdriver being a better solution, and this latest issue plaguing my >> watir tests having led me through a half day excursion in the doc and on >> the web may be the deal-killer unless I can now come up with a reasonable >> solution in a timely fashion. So I would be extremely grateful if someone >> who has been down this road before could provide me with guidance. >> >> Thanks, >> Ben >> >> -- > Before posting, please read http://watir.com/support. In short: search > before you ask, be nice. > > [email protected] > http://groups.google.com/group/watir-general > [email protected] > -- Before posting, please read http://watir.com/support. In short: search before you ask, be nice. [email protected] http://groups.google.com/group/watir-general [email protected]
