CODEWITHSUNDEEP
seleniumselenium-webdriverselenium-webdriver4
MBaas
MBaas

Reputation: 7530

EXCEPTION: stale element reference: element is not attached to the page document

My HTML-Page contains (among other stuff) this bit:

<ol id="links">
<li id="links_1"><a href="http://stackoverflow.com">stackoverflow</a></li>
</ol>

In my code to test the page, I then do:

el←FindElementById'links_1'
(ACTIONS.MoveToElement el).Build.Perform

and this crashes with

EXCEPTION: stale element reference: element is not attached to the page document
  (Session info: chrome=81.0.4044.129)

However, this error doesn't seem to be justified, as the element is still alive:

      el.Displayed
1
      el.Text
stackoverflow
      el.Location
{X=56,Y=282}

How can I fix this problem?

(The environment is APL. I've left out a few APL-details here because I feared they might be avoidable "distraction" from the core-issue)

During my research before posting, I saw the question stale element reference: element is not attached to the page document but it doesn't seem to apply:

I also went through the reference, but this explanation did not help.

Also, there is no looping going on and nothing changes the page. It's really straightforward: GoToUrl * Find * MoveToElement.

I removed the chromedriver-tag, as I can repro this with Firefox and geckodriver. However, with geckodriver, I get "EXCEPTION: Web element reference not seen before:" when I do MoveToElement - but I can do el.Click and access its properties in exactly the same way that as with Chrome.

Update: a coworker investigated this a bit deeper (beyond my comfort zone) and found that before throwing this "stale exception", there is (I'm not sure how to word this properly and where exactly it occurred) a 404-exception. I just know 404 as an HTTP Status-code - that's all it means to me. But clearly the browser was not asked to navigate anywhere, so I can't be related to an HTTP404. Does that perhaps ring some bells with anyone more familiar with the internals of WebDriver?

Upvotes: 1

Views: 486

Answers (1)

MBaas
MBaas

Reputation: 7530

This was a complex and multi-layered problem, but when I finally removed all layers - it worked! The key-factor which caused this problem:

  • due to a fault in the way I had written the test caused it to be executed twice - and the 2nd run always exposed the problem.
  • I had instantiated ACTIONS in the test-framework and was not aware of a critical feature: it continuously builds a chain of actions, any Build.Perform..-steps just added to that. Solution: create separate instances of every run (possibly, since it's fairly lightweight) or call ACTIONS.Reset(requires WebDriver4). I've never had issues with WD4 (although it still is in alpha) - but this gave the ultimate reason to switch!

Upvotes: 1

Related Questions