--
You received this message because you are subscribed to the Google Groups "Selenium Developers" group.
To post to this group, send email to selenium-...@googlegroups.com.
To unsubscribe from this group, send email to selenium-develo...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/selenium-developers?hl=en.
--aditya
--
You received this message because you are subscribed to the Google Groups "Selenium Developers" group.
To post to this group, send email to selenium-...@googlegroups.com.
To unsubscribe from this group, send email to selenium-develo...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/selenium-developers?hl=en.
* The first thorny is issue is what do we mean when we say a page is
"loaded"? Is it when the "load" event has fired? Or that the page
quiesced? When there are no outstanding XmlHttpRequests left? When
there's no more javascript to left to be executed via "setTimeout"?
Any of these definitions can be argued to be "wrong". None of them are
universally "correct"
* Especially when using native events, it's hard to tell when a user
interaction will push the app into a state where blocking would be
required. If refreshes are decoupled from the flow of JS execution
(eg: using setTimeout) then things get even trickier.
* There are multiple race conditions between issuing an event and
figuring out that the page is reloading. Guaranteed, we'll lose that
race every odd now and again.
Given these constraints, the "best' we can probably do is to follow a
two-fold approach:
1) Return from commands as soon as is reasonable, but sniff for page
reloads before executing the _next_ command.
2) Educate users to be more explicit about what they're actually waiting for.
As an example of that second point, if I'm waiting for a page to be
ready for me to log in, all I need is for the username, password and
submit button to be present. I don't need the footer of the page or
ads to have been loaded. Waiting for the last of these elements in the
DOM (probably the submit button) is clearer than "wait until the page
has loaded".
WebDriver offers mechanisms to help with this. The implicit waits we
added recently allow you to wait for the presence of an element in the
DOM. It's possible that we could use the same timeout for checking for
visibility where that is a requirement too. To complement implicit
waits, we also have the "Wait" interface and "WebDriverWait"
implementation where we want to spell out the interactions, and the
"PageFactory" and the "ElementLocatorFactory" implementations for use
with Page Objects.
I think that we're doing a reasonable job balancing blocking and
non-blocking right now. It's certainly not perfect, and there's always
room for improvement (as some of the emails I see spell out clearly)
and I acknowledge that. If anyone's got practical advice on how to
improve things, I'm all ears :)
Simon
One issue I've found is the combination of native events and waiting
for elements to be present. If the page has not fully "loaded",
elements may move as more elements are rendered, and so native clicks
may click at the wrong coordinates. Certainly having hooks to detect
load-states could be handy, i.e. haveAllXhrsLoaded, isPageIdle, ...
methods.
will indicate whether the document is complete. This works on (at
least) modern Firefox versions, IE and Chrome.
Simon