question-mark
Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Firefox, |wait for visible| and exceptions

See original GitHub issue

Apologies for the wall of text, there are some nuances to this issue that I hope to get across 🙂

Lately, we’ve been switching several projects from Chrome to Firefox because of unsolved issues in chromedriver. After switching, the test scripts often need some adjustments before they work again. Most of those adjustments are either small and easy or project-specific, but there is one trend that might qualify for a HSAC PR.

Namely, there are two exceptions that plague the use of |wait for visible| when running tests on Firefox: StaleContextException in general and a WebDriverException with message “TypeError: can’t access dead object”. Both have a tendency to randomly occur when waiting for something to become visible while the page content changes. This occurs frequently when waiting for e.g. a login attempt to be successful or a payment to complete.

There is a workaround for StaleContextException: if you |set search context to| any search context (even css=body will do), BrowserTest’s invoke method swallows the exception and tries again: https://github.com/fhoeben/hsac-fitnesse-fixtures/blob/2f59a14403bacce18deea99834abe574bde0dd68/src/main/java/nl/hsac/fitnesse/fixture/slim/web/BrowserTest.java#L90-L98

However, the only workaround for the WebDriverException with message “TypeError: can’t access dead object”, is to somehow make sure that the browser will not navigate while the |wait for visible| is waiting. That is not always possible (e.g. a page that refreshes until a job has finished running), so I decided to look if I could make BrowserTest swallow this exception as well. I first tried swallowing it in waitForVisible itself, but then it would still occur in TryAllFramesConditionDecorator.invokeInFrames (because of wrapConditionForFramesIfNeeded). Then I tried to swallow it at the same spot where StaleContextException is swallowed. That did the trick, and works by adding something like this to BrowserTest.invoke:

} catch (WebDriverException e) {
    if (e.getMessage().toLowerCase().contains("can't access dead object")) {
        // This is a dead object exception, just try again
        return invoke(interaction, method, arguments);
    } else {
        throw e;
    }
}

Note that this particular WebDriverException is Firefox-specific, and occurs when trying to access a DOM object when its parent document has been destroyed (i.e. navigated away from). More information at https://blog.mozilla.org/addons/2012/09/12/what-does-cant-access-dead-object-mean/.

So my question is: would you accept a PR that makes BrowserTest swallow both exceptions by default? Or at least the WebDriverException? For the StaleContextException, the workaround results in boilerplate code and makes using HSAC with Firefox a bit of a hassle, but at least it works. For the WebDriverException however, there are cases where it is necessary to be able to swallow it, and I can’t think of any use for stopping the test on it. Even if you’d want to use it to detect unwanted navigation, the low chance of it popping up (about 1 in 5 times) makes it very unreliable for that purpose. I’d argue that swallowing this one by default would be a good idea, at least when browsing with Firefox.

Issue Analytics

  • State:closed
  • Created 5 years ago
  • Comments:5 (5 by maintainers)

github_iconTop GitHub Comments

1reaction
JessefSpecialisterrencommented, Sep 28, 2018

Closing now that #233 has been merged 🙂

0reactions
JessefSpecialisterrencommented, Sep 27, 2018

Managed to create a test that reliably reproduces the ‘can’t access dead object’ exception and used it to create and verify PR #233!

Read more comments on GitHub >

github_iconTop Results From Across the Web

Element not visible exception with firefox webdriver
This code will check the expected condition (visibility of the close_bttn object) in every Y milliseconds. The wait time is X seconds. Share....
Read more >
Pop-up blocker settings, exceptions and troubleshooting
Learn what pop-up windows are and what settings Firefox has for blocking or allowing them.
Read more >
Element not visible exception with firefox webdriver
This code will check the expected condition (visibility of the close_bttn object) in every Y milliseconds. The wait time is X seconds. Gyorgy.Hegedus...
Read more >
Selenium Wait Commands : Implicit, Explicit & Fluent Wait
Implicit Wait directs the Selenium WebDriver to wait for a certain measure of time before throwing an exception. Once this time is set, ......
Read more >
ElementNotVisibleException Exception thrown when element ...
Maybe IE is a bit slower than Firefox and it is invisible when your code tries to access it in IE. See if...
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Dev.to Post

No results found

github_iconTop Related Hashnode Post

No results found