On Wed, Jun 13, 2012 at 8:36 AM, Ben Armstrong <[email protected]> wrote:
> On 13/06/12 05:16 AM, Chuck van der Linden 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. >> > > Unfortunately not, and disentangling it all to make a minimal failing test > case I could post would be tricky (I started this effort and gave up after > about 15 minutes). Before I go to all that effort, I would just like to > discuss the higher level problem with watir-webdriver. As for the > implementation details, I can likely work that out on my own following the > discussion. > > > 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<https://github.com/watir/watir-webdriver/wiki/AJAX-and-waiting-for-elements> >> > > True, but that's just the same approach the stackexchange poster was > complaining about, and I agree: why can't watir-webdriver know that the > click is going to cause a new page to be loaded and block until it is > loaded? Why did the same test work with watir, and not with watir-webdriver > (the same Javascript double-click-prevention code was attached as an > onclick handler in that case too, and yet the test worked)? > How would webdriver know the behavior of your application the 2 only communicate thru the browser. I am guessing that the tests passed in watir and not in watir webdriver because of the OS and how native events are handled https://groups.google.com/forum/?fromgroups#!searchin/webdriver/send$20keys$20windows$20wait$20for$20page$20to$20load/webdriver/7K2QWGVNCYo/wqLCoaH6CzYJ what happens when you try the tests in different browsers? > > If I need to, I will inject something extra into the page and use one of > the approaches listed in the doc above to detect it. It just seems like > some unnecessary extra effort to work around a regression in > watir-webdriver, rather than a step forward. Also, that doc doesn't > specifically address "what if the page looks exactly the same as it did > before?***" > > Every time my project suffers delays like this to work out issues with new > tech that not all project members understand, I come under fire for > spending too much time on things that don't seem to matter to them ("what > was wrong with the old technology this replaces? is the new technology > worth the extra effort you're putting into it?") > > Ben > *** In at least one case, the button is called "Refresh" and retrieves a > page of output, rendered in a single <pre>..</pre> element that may or may > not differ from last time, depending on output generated from a command run > on a server contacted by the script. I had hoped for a generalized and > transparent solution that doesn't care what the resulting page looks like > and just knows "a new page was generated, even if it looked exactly like > the old one". > > > -- > 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<http://groups.google.com/group/watir-general> > watir-general+unsubscribe@**googlegroups.com<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]
