ByChained should provide an atomic behavior

[lukeis]

Originally reported on Google Code with ID 6093

What steps will reproduce the problem?
1. Construct a ByChained locator over several By clauses
2. Prepare a page where the ByChained locator will locate a target element
3. Search for the element using the ByChained locator, while removing DOM nodes in
the search path from the deepest element to the surface one (introducing a race condition)

What is the expected output?
It should either return the targeted element (which would later become stale), or throw
a NoSuchElementException.

What do you see instead?
In some cases, a StaleElementReferenceException is thrown.

Selenium version:
OS: Windows 7 64 bits
Browser: Firefox
Browser version: 22.0

The StaleElementReferenceException is probably induced by an intermediate element in
the search path that becomes stale while findElements() is applied to it.

The contract and the semantic of findElement and findElements do not imply that an
action is performed on any found element, which would mean that the targeted elements
are either found or not, possibly throwing a NoSuchElementException.
Therefore, a thrown StaleElementReferenceException indicates that the concept of finding
elements is not abstracted enough in ByChained.

Reported by jeremiah.menetrey on 2013-08-13 12:50:53

[lukeis]

Reported by barancev on 2013-08-13 22:40:59

• Labels added: Component-WebDriver, Lang-Java

[lukeis]

This issue was closed by revision c51550c542ab.

Reported by barancev on 2013-08-21 00:38:56

• Status changed: Fixed

[lukeis]

Reverted back. First solution was too vague and premature. I need to think it more carefully.

Reported by barancev on 2013-08-21 07:13:31

• Status changed: Accepted
• Labels removed: Status-Untriaged

[lukeis]

As for now, I see two implementable solutions with their pros and cons:

If a StaleElementReferenceException is thrown
1. throw away all results so far and try again;
2. throw away the branch of stale elements up to one that is not stale, and continue
from there.

(1) has the advantage of being easily implementable, but might introduce a time overhead
for pages with a very deep DOM.
(2) overcomes that problem but introduces a memory overhead, as all elements found
so far should be stored in a tree.
Both solutions should also stop trying when the time spent exceeds the driver's timeout
value.

Mixing both solutions should also be possible, e.g. keeping only n levels of the tree
for (2) and if its not possible to get to the previous level, use (1). I'm not sure
however that there is much benefits in doing so, and I implemented myself a very dumb
version of (1) that fits my purposes.

Those solutions suppose that ByChained provides a 'Best effort' contract, but it might
not be enough.
The alternative is to work on a snapshot of the complete DOM, which will provide a
perfectly atomic behavior, i.e. it guarantees that the returned elements were valid
at one particular moment in time, as if they were grabbed all at once. However I doubt
that Selenium is currently capable of providing such a snapshot, and it might be too
much to do just for the sake of ByChained.

Reported by jeremiah.menetrey on 2013-08-21 17:20:26

[lukeis]

You see ByChained is not in the "main" package, it is a part of PageObject pattern implementation.
It is not suppossed to be used directly. So can break "official" contact.

After some thinking I decided to *not* change ByChained. Instead I'm going to introduce
a new parameter to @FindBys annotation -- something like "stale reference tolerance
level". And it will probably follow your suggestion 1.

Reported by barancev on 2013-08-21 18:57:14

[lukeis]

Reported by luke.semerau on 2015-09-17 17:45:55

• Labels added: Restrict-AddIssueComment-Commit