Retry navigation if unload alert disappears

[elliterate]

When a Selenium driver interaction raises an unexpected alert error, Firefox 59+ automatically dismisses the user prompt that caused it. Therefore, if the driver reset triggers an unload alert, we cannot wait to handle it until we receive an unexpected alert error. Instead, we must retry navigation and proactively attempt to accept any alert that appears.

[elliterate]

This fixes the "Timed out waiting for Selenium session reset" errors in the builds using Firefox Beta and Firefox Nightly.

[twalpole]

Has this been reported to firefox/geckodriver? Is it intentional behavior?

[elliterate]

Yes and yes. I reported it as mozilla/geckodriver#1171 and was informed that it was deliberately implemented in https://bugzilla.mozilla.org/show_bug.cgi?id=1416284.

[elliterate]

BTW, I realized after I submitted the pull request that my implementation wouldn't be sufficient, since it adds a delay to every session reset to handle a rare scenario. I'll keep working on it, but I'm also happy to hear any thoughts you have on how best to handle this.

(Also, as the build shows, it appears to be getting stuck on some test.)

[twalpole]

Well that's a depressing behavior decision - So you tell the browser to go to another page and FF decides to auto-dismiss any confirm/prompt (rather than accept) and prevent the page change - why would anyone want that as the default? It also obviously doesn't align it with chromedriver (as stated) or things would still work (since it currently works fine with chromedriver)

[twalpole]

@elliterate Yeah -- it would be better to catch the error and then try navigating agin within accept_modal so the sleep isn't always needed.

[elliterate]

So you tell the browser to go to another page and FF decides to auto-dismiss any confirm/prompt (rather than accept) and prevent the page change

It doesn't actually auto-dismiss on navigation—only if you do something that triggers an unexpected alert error. But that's exactly what Capybara does when it proceeds to poll for an empty page body.

And because it auto-dismisses the alert at the same time that it raises an unexpected alert error, attempting to accept the alert in the error handler will no longer work. You'll have to re-attempt the navigation, then immediately go looking for an alert to accept.

Well that's a depressing behavior decision

We're in violent agreement.

But it might get worse. According to the latest draft WebDriver specification, they intend for user prompts triggered by beforeunload handlers to always be dismissed, which, if my understanding is correct, means that one would effectively be trapped on such a page.

[twalpole]

@elliterate Ugh --- Definitely sounds like that would be the case, hopefully someone pays attention to your issue report - I often have the feeling the people writing the spec don't actually ever use the things they're writing the specs for, but maybe it's just an oversight.

[elliterate]

While I've updated my branch with what I believe is a reasonable solution, I discovered mozilla/geckodriver#1181 in the process, which likely blocks me from verifying it with passing tests.

[twalpole]

@elliterate The beta build still fails, are you saying that's because of the geckodriver issue? If so tis there any benefit at all to merging this at the current time?

[elliterate]

The beta build still fails, are you saying that's because of the geckodriver issue?

That's correct.

If so tis there any benefit at all to merging this at the current time?

I don't believe we'd see an immediate benefit, no. That issue is preventing this fix from being useful, as it's preventing the find_xpath('/html/body/*') from raising an unexpected/unhandled alert error.

[twalpole]

Closing in favor of a66ff2e