I am going to say yes this is my assumption based on the fact watir itself uses the win32-api-1.4.8.gem which I am guessing gives it the ability to know the browser and native OS events a bit better https://github.com/djberg96/win32-api but as far as the original problem of it not waiting for the browser to load I am going again to guess there is probably a way to hook into the events happening on the page to check if its done or not (but that's just me)
On Wed, Jun 13, 2012 at 9:53 AM, Ben Armstrong <[email protected]> wrote: > On 13/06/12 10:33 AM, Oscar Rieken wrote: > > > How would webdriver know the behavior of your application the 2 only > communicate thru the browser. > > > My naive answer would be "however watir knew before I switched to > watir-webdriver". :) ... > > > 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 > > > That thread is an interesting read, and although it covers much of the > same ground I've covered already before starting this thread, I now have a > notion (even if only a fuzzy one) of how "keyboard and mouse emulation > [done] at the OS, not browser, level" might lead to problems. Is that to > say that with watir, that keyboard/mouse emulation *was* done before at the > browser level? If so, that gives me a satisfactory answer to report back to > my team. > > > what happens when you try the tests in different browsers? > > > My recollection is that with firefox, all tests failed for unrelated > reasons. Since I wasn't targetting firefox with the code being tested at > the time, I did not investigate further. I'd have to fall back to an older > version of my tests now to get you that info, and can still do that if it's > relevant, but at this point, I need to switch back to dealing with other > more pressing projects. > > Thanks for the clarification. I'll report to my team: > > The OS-level mouse/keyboard interface on Windows that webdriver uses does > not provide webdriver with sufficient information about what's going on for > watir-webdriver to really know when the browser is done responding to a > click, whereas watir had a browser-level view of what was going on and was > able to know when the next page was done, even when the submit was mediated > by intervening Javascript code. Embedding a unique id in each page will > allow us to always know if a new page was displayed. That seems to be the > only general solution available. > > > Is that a fair charaterization of the problem and its solution? > > Thanks, > Ben > > > > > >> >> 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 >> [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] > > > -- > 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]
