Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for dynamic module base elements #557

Closed
erdi opened this issue Dec 20, 2018 · 5 comments

Comments

Projects
None yet
3 participants
@erdi
Copy link
Member

commented Dec 20, 2018

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

This comment has been minimized.

Copy link

commented Feb 27, 2019

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

This comment has been minimized.

Copy link
Member Author

commented Feb 27, 2019

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.

@fluviusStan

This comment has been minimized.

Copy link

commented Mar 5, 2019

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

This comment has been minimized.

Copy link
Member Author

commented Mar 6, 2019

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

@fluviusStan

This comment has been minimized.

Copy link

commented Mar 6, 2019

@erdi Thanks for your answer.

erdi added a commit to geb/geb that referenced this issue Apr 4, 2019

Change the type of the field holding context elements in navigators t…
…o Iterable as it allows for lazy evaluation in preparation for supporting dynamic navigators

Part of geb/issues#557

erdi added a commit to geb/geb that referenced this issue Apr 4, 2019

Remove EmptyNavigator and AbstractNavigator, rename NonEmptyNavigator…
… to DefaultNavigator in preparation for supporting dynamic navigators

Part of geb/issues#557

erdi added a commit to geb/geb that referenced this issue Apr 4, 2019

erdi added a commit to geb/geb that referenced this issue Apr 4, 2019

Change the type of the field holding context elements in InnerNavigat…
…orFactory to Iterable as it allows for lazy evaluation in preparation for supporting dynamic navigators

Part of geb/issues#557

erdi added a commit to geb/geb that referenced this issue Apr 4, 2019

Do not consume the iterable with context elements in AbstractNavigato…
…rFactory to allow for lazy evaluation in preparation for supporting dynamic navigators

Part of geb/issues#557

erdi added a commit to geb/geb that referenced this issue Apr 12, 2019

erdi added a commit to geb/geb that referenced this issue Apr 12, 2019

Ensure that the dynamic attribute used when constructing Navigators i…
…s interpreted using Groovy truth regardless of type and is not interfering with attributes used for selecting elements

Part of geb/issues#557

erdi added a commit to geb/geb that referenced this issue Apr 12, 2019

erdi added a commit to geb/geb that referenced this issue Apr 12, 2019

erdi added a commit to geb/geb that referenced this issue Apr 26, 2019

erdi added a commit to geb/geb that referenced this issue Apr 26, 2019

erdi added a commit to geb/geb that referenced this issue Apr 26, 2019

erdi added a commit to geb/geb that referenced this issue Apr 26, 2019

Add a minor performance improvement to geb.navigator.DefaultNavigator…
….filter(Map) to not create a new navigator when a dynamic navigator is requested without any additional attribute constraints which is a situation that happens for some internal calls

Part of geb/issues#557

erdi added a commit to geb/geb that referenced this issue Apr 26, 2019

erdi added a commit to geb/geb that referenced this issue Apr 29, 2019

erdi added a commit to geb/geb that referenced this issue Apr 29, 2019

erdi added a commit to geb/geb that referenced this issue May 6, 2019

erdi added a commit to geb/geb that referenced this issue May 6, 2019

erdi added a commit to geb/geb that referenced this issue May 6, 2019

erdi added a commit to geb/geb that referenced this issue May 8, 2019

erdi added a commit to geb/geb that referenced this issue May 8, 2019

erdi added a commit to geb/geb that referenced this issue May 8, 2019

erdi added a commit to geb/geb that referenced this issue May 8, 2019

erdi added a commit to geb/geb that referenced this issue May 8, 2019

erdi added a commit to geb/geb that referenced this issue May 8, 2019

erdi added a commit to geb/geb that referenced this issue May 9, 2019

erdi added a commit to geb/geb that referenced this issue May 9, 2019

erdi added a commit to geb/geb that referenced this issue May 9, 2019

erdi added a commit to geb/geb that referenced this issue May 9, 2019

erdi added a commit to geb/geb that referenced this issue May 10, 2019

erdi added a commit to geb/geb that referenced this issue May 10, 2019

erdi added a commit to geb/geb that referenced this issue May 11, 2019

erdi added a commit to geb/geb that referenced this issue May 11, 2019

@erdi erdi self-assigned this May 12, 2019

@erdi erdi added the New feature label May 12, 2019

@erdi erdi modified the milestones: 2.4, 3.0 May 12, 2019

erdi added a commit to geb/geb that referenced this issue May 12, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.