Add support for dynamic module base elements

[erdi]

It's a common problem in single page apps that module base elements go stale as the DOM is re-rendered by the js framework used upon model change.

Consider adding an ability for a module to declare itself as "dynamic" so that its base is not calculated and stored at initialisation time but resolved every single time a Navigator method is called on it.

[thokari]

If there was a chance to extend this behaviour to every Navigator, or rather page content definition, that would be seriously awesome.
That would be solving this old issue, basically.

I'd argue that in cases where the browsers page did not change, a StaleElementReferenceException should never be thrown, unless it was tried at least once to refresh the element from its selector.

[erdi]

The current idea for the implementation of this to add a "special" predicate (special in the sense that it won't be translated to an attribute selector - text is one example of such predicate) for Navigator creating methods (like $()). This means that this "dynamic" behaviour could be applied to any Navigator and we could possibly make it configurable to be set to true by default on all Navigators. But the are two considerations that you should keep in mind:

1. Enabling it on all navigators by default will have significant performance impact - each method call that will result in a web driver command will generate at least double the amount of commands and for navigators that have a long creation path (i.e. when you do $().find().find()) this will be even more
2. StaleElementExceptions will still occur in certain situations as the operations will not be atomic - a problem which is raised in the issue you linked to. So for click() on a "dynamic" navigator first a web driver command will be executed to refresh the web elements which underpin the navigator and then another web driver command will be executed to click on the element that was found - if between the two commands the element is removed from the DOM the exception will occur. While less likely it's far from impossible especially in highly asynchronous apps with frequent DOM redraws and will be exacerbated for navigators with long creation paths.

Therefore this is not a silver bullet and should be used sparingly when the navigator actually is likely to be dynamic.

[fluviusSP]

So for click() on a "dynamic" navigator first a web driver command will be executed to refresh the web >elements which underpin the navigator and then another web driver command will be executed to click

@erdi Is there a possibility to obtain this behaviour right now using GEB framowork methods?

[erdi]

No, not that I'm aware of, @fluviusStan. This ticket is actually about making it possible.

[fluviusSP]

@erdi Thanks for your answer.