Extensions: Provide a means for extensions to override the default wait mechanism

[jeremybramwell]

Goal:
Allow Add-on WebExtensions to override the default wait mechanism. This would allow a plugin to be created to address unique situations where the built in mechanism isn't reliable.

Requirements:

• Allow an Add-on WebExtention to register a wait function that will override the default wait.
  • This might be implemented as a special message type "OverrideWait" that the WebExtension can send to the SeleniumIDE context.
  • If a more generalized mechanism exits for registering an Add-On with Selenium IDE then this registration might be a part of that mechinism.
• If there is more than one type of wait mechanism then it might be best to let an add-on override each mechanism independently so that only the ones that need to be altered are changed.
  • For example there might be a "Wait for document onready" and a "Wait for Element to exist" type of waits. An Add-on might only be ineterested in overriding some subset of these wait types.
• The Add-on might be applicable to the current page or situation, and in that case the addon should be able to tell SeleniumIDE that the default wait function should occur instead.
  • This might be handled via the registration mechanism if there is some registration that occurs with each page load. The Add-on can detect if the page is a type that should use the overridden wait function and if so the add-on registers tha override. If not, the Add-on doesn't register the override.
  • The might be handled on a "per wait" basis where the add-on can reply to a message from SeleniumIDE requesting that an override wait occur with a response indicating that the requested wait has been performed and it is ok to proceed OR that the wait was not performed and the default wait (or the next wait override) should be used instead.

Use Case:
Our web application is a single page web app, and so document on ready doesn't really apply once you have entered the app. The existence of an element in the DOM isn't always a reliable indicator if the next test step can proceed since after a user action occurs the application sometimes enters a "wait state" where some overlay indicating progress is displayed and events are ignored until the server responds to the user action. A generic pause is one way to workaround this situation but A) it is often hard to apply a pause that is long enough for every case without making the test runner painfully slow. B) we also want to use the runtime of these tests to monitor system performance, so ideally we want the script to wait exactly as long as needed for the system to respond to the prior step.
In the previous iteration of Selenium IDE we were able to implement an add-on/plug-in that overrode the default wait function so that it looked at some global state info exposed by our application framework to see if the application was waiting for a response from the server.

Alternative:
An alternative approach that would work for us, but may not address some other potential use cases for the wait override approach would be to define a convention such as a global value e.g. window.seleniumIDE.waitOverride that our application framework could update to "WAIT" when it begins waiting for a response from the server and then update to "READY" when ready for the next test step. SeleniumIDE's wait functions could then be changed to check for this value and override the behavior if it exists. There are any number of ways this might be implemented. SeleniumIDE could also inject some special functions that our web app could call so that Selenium IDE didn't need to poll a global value.

[corevo]

Thanks for the detailed info,
I understand that the current wait mechanism is not good enough in SPA cases.
As the element can appear, but does not respond.
But Selenium IDE by default, waits for all xhr requests to finish before proceeding to the next step, did you check that?
Is the wait for xhr requests to finish not enough?

[jeremybramwell]

Our app uses websockets. We can force the app to fallback to using XHR requests, but then it uses "long polling" to allow for the server to push changes to the client, so I imagine that might cause further problems as there is always an XHR request pending.

On top of that the "waititng for response" state where user input is ignored doesn't end until the response has been fully processed. There are a few situations where the processing is broken up into two phases by a setTimeout to allow for some layout to occur.

[corevo]

I don't like falling back in test environment, AUT shouldn't know it's being tested.
Right now, with the current API #79 gives, it still waits automatically, but since it is SPA, it shouldn't be long, you can implement a new command, that will wait the extra time necessary.
In any case you can have a look here, it'll show you how to add new commands, although the example is sync it can also be async.

[jeremybramwell]

Thanks for pointing me to that, I hadn't noticed that you had the Extention API in place. I was waiting for the ground work for the Extension API to get far enough along before getting some resources committed on our side to look into implementing whatever is need to achieve the wait (this issue) and the custom locator strategy I described in #104. I haven't looked at the code since just after you brought in sideEx. I'll carve out some time to take a closer look at the current API and update this issue and #104 accordingly.