0

I've started using Selenide recently, and I'm loving the fluent code it allows. I do have strange issue with ElementsCollection, however.

$$("some ref").filterBy(not(attribute("an-attr-that-should-not-be"))).getTexts()

This query intermittently returns stringified StaleElementReferenceExceptions, and I can't understand why.

If I run the query in the debugger, it returns valid values, while during normal runtime (single thread application), this is what I get.

The target element is a GWT combo box results list.

Could someone please point me in the right direction?

Update: if it's relevant, I'm using InternetExplorerDriver.

Maxim Kumpan
  • 2,545
  • 2
  • 19
  • 23

3 Answers3

1

Chrome and ChromeDriver specifically fire off StaleElementReferenceException like its the point of your test - any time an element is no longer visible the WebElement reference you have to it becomes invalid and you must look it up again. If the combo is showing/hiding or changing those could cause this (need more details on which combo and what seems to cause it for more specific) - try looking up the element when you expect to use it instead of reusing the reference again and again.

Colin Alworth
  • 17,801
  • 2
  • 26
  • 39
  • Thank you for your response, however, nowhere in my question does it imply that I am using vanilla WebElement, or re-using one at that. I have provided a code sample that is giving me issues. Can you please read the entire post and see if you know what's happening here? – Maxim Kumpan Oct 28 '15 at 04:00
  • How ever you are using selenium, old 1.0 API or current WebDriver, if you are using Chrome and the ChromeDriver you will get stale exceptions when something is hidden. Aside from one line of code, you have essentially no details about your environment, so I have to go for the most likely setup. – Colin Alworth Oct 28 '15 at 04:22
  • no, nothing is hidden. Sorry about the missing info. Added to op - I'm using IEDriver. If I use the driver directly it all works, while using the selenide $$ wrapper does not. – Maxim Kumpan Oct 28 '15 at 05:39
  • Eh, my bad, using webdriver directly yields identical results. Makes me wonder if the bloody div refreshes THAT often. – Maxim Kumpan Oct 28 '15 at 07:12
  • If you are using IE, then I'm not sure this applies - while I haven't directly used IEDriver in a while, I distinctly remember ChromeDriver being crazy about anything being stale, more so than any other driver impl. I'd focus instead on what is happening on the page - is it possible that the combo box itself is being rebuilt/replaced entirely, or are there known issues in your version of IEDriver. Building a small test case of your app might help, but I'm at a bit of a loss from what has been shared so far. – Colin Alworth Oct 28 '15 at 14:35
0

Found the problem. Apparently, the Selenide ElementsCollection cached a previous version of the element list, which updated a lot slower than anticipated, and was trying to access this ghost data when retrieving texts.

Fixed by using $$ where the list is iterated, instead of the usual static constants in class header.

Maxim Kumpan
  • 2,545
  • 2
  • 19
  • 23
0

My solution for this problem was very simple and straight. I just set the timeout for the search of an element around 10 seconds and it worked. It can be done only with one string: Configuration.timeout=10000 The value is in milliseconds, of course.

Konstantin Firsanov
  • 64
  • 3