[
https://issues.jboss.org/browse/ARQGRA-280?page=com.atlassian.jira.plugin...
]
Jan Papousek commented on ARQGRA-280:
-------------------------------------
To solve the performance issue, I suggest to refactor GrapheneProxy.FutureTarget
interface:
{code}
public interface FutureTarget {
Object getTarget();
}
{code}
to
{code}
public interface FutureTarget {
Object getTarget(boolean cacheAllowed);
}
{code}
Refactor handling of staleness to improve performance
-----------------------------------------------------
Key: ARQGRA-280
URL:
https://issues.jboss.org/browse/ARQGRA-280
Project: Arquillian Graphene
Issue Type: Task
Affects Versions: 2.0.0.Alpha3
Reporter: Jan Papousek
Assignee: Jan Papousek
Fix For: 2.0.0.Alpha5
Original Estimate: 4 hours
Remaining Estimate: 4 hours
The current situation of handling staleness is it works purely accidentally in some cases
and it prevents any caching of web elements.
Imagine the following code:
{code}
Action action = new Actions(driver).moveToElement(element).build();
... // some action causing staleness
action.perform();
{code}
The previous code doesn't throw StaleElementReferenceException only in the case when
the action causing staleness finishes before the requested action starts performing and
when there is no caching of web elements. Currently Graphene can't force the action to
perform again when StaleElementReferenceException is thrown.
In the case of caching the scenerio would be:
# element is loaded and put to the cache
# ... some actions ...
# action causing staleness is performed
# the requested action starts performing
-- cached element is used => StaleElementReferenceException
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see:
http://www.atlassian.com/software/jira