NoSuchWindowException when using chrome v80 and chromedriver v80.

[黄杰]

When i use chrome 79/78 and chromedirver 79/78 for firefrox, everything works fine. but after I upgrade chrome to version 80 and chromedirver to v80. My selenium script staring to throw No Such Window exception.

I have a script doing some work on a webpage which has three iframes, I switch to the second iframe. Then check if a button is displayed and clickable using expected condition to check if that button is displayed and clickable for 600s, 0.5s per time. But it throw No such window exception right away.   It works for on chromedirver 78/79 and firefox but not on chromedriver 80. I have to add sleep before checking this button or add ignored exceptions parameter to workaround this issue. 

I raised a report on gitbub to selenium but i think issue could be with chromedirver. Chromedirver 80 had fixed a "bug" which is suspicious.

ChromeDriver 80.0.3987.16

Supports Chrome version 80

• Fixed Load page was aborted when using a proxy.
• Chromedriver now waits for Current frame to load.
• ChromeDriver log will include the port used by the driver. Enabled SetGeoLocation for w3c mode.
• Added missing Alert text for UnexpectedAlertOpen status. Improved message when CRX2 Extension is loaded.
• Fixed a potential race condition in ExecuteGetPageSource. ChromeDriver will add --ignore-certificate-errors flag when acceptInsecureCerts capability is true
• Updated the error message and return status for no such execution context Fixed: ChromeDriver may block indefinitely while waiting for pending navigation.
• Added SameSite attribute to AddCookie and GetCookie.

For more details, please see the release notes.

https://chromedriver.chromium.org/downloads

Issue detail description can be found here: https://github.com/SeleniumHQ/selenium/issues/8017

Could you please check why issue appears on chromedriver 80 only?

 

[T Crichton]

The log (posed on the Selenium issue) shows that the tab in which the search is made is destroyed and recreated during the Find. This is probably initiated by the preceding ClickElement or ExecuteScript commands; these occur in the same second as the final FindElement, so structural changes to the document do not have time to stabilize before the find runs.

In previous version, the NoSuchWindowException returned as an unknown exception type and was thrown as either WebDriverException or just Exception. That would explain why the exception has changed.

We believe the code to wait for current frame to load is correct, however, cases where the context is destroyed cannot be handled by ChromeDriver. When a command is running within a context and that context is destroyed, the command must fail. Look for executionContextDestroyed in the logs.

Our usual advice in this case is for the code to catch the exception, switch to the Default context, then back to the target frame, and retry the search.

In this case, simply ignoring the exception and trying again (without repeating the frame switch) is working. I think that's because the frame ID is reused when the frame is recreated. It may not be a robust solution.

[August Huang]

Hi,

I started with login url, then it redirects me to one webpage, it has multiple redirects before reaching this page.

Then on this page, I hover and element(menu), then try to click the hyperlink on this pop-up.

Then page was redirected to the final page that I need. this page has three iframes, I need to switch to the second iframe and do some work here(find an element first.....). All of those redirects and operation are on the same Tab. 

qc1.log:

qc10.log:

I hover over the menu, but i did not click it. But script continue runing, it tried to find the iframe but since i didnot click the hyperlink, so page didn't change, iframe will not appear.

qc11.log:

another change:

I hover over and clicked the hyperlink using JS.

self.driver.execute_script(

            'document.querySelector("nav.mc-header-app-switcher-region > div > ul > li:nth-child(2) > ul > li:nth-child(2) > div.mc-app-group-dropdown > ul > li > a").click();')

This click started in the log at line 4621, completed at line 4855.   

Then i try to find the iframe I needed. Then switch to this iframe. Those two steps completed successfully as well, from line 4856 to line 5285.

Then the i try to find a button, but failed with nosuchwindow exception. This step starts at line 5286.

Question:

why executionContext was destroyed after I try to find a button in that iframe? And navigate to frame and create a new execution context after SwitchToFrame? 

I have to agree those steps all in 1 second, really quick.

qc115.log:

This time, I add 5 seconds sleep.  executionContext was also destroied after I try to find a button on that iframe. 

Actually, no matter how long do i sleep, executionContext would be destroyed after I try to find a button on that iframe. 

This proof that executionContext's destroy is not relate to time.

Question:

There is a frame navigation and executionContext creation, that is probably because the click take me to new page so we need a new execution context. But why there is no frameNavigated log during SwitchToFrame? Why the execution context did not change after switched to new frame?

Log location 

在 2020年2月12日星期三 UTC+8上午3:26:55，T Crichton写道：

[T Crichton]

Question:

There is a frame navigation and executionContext creation, that is probably because the click take me to new page so we need a new execution context. But why there is no frameNavigated log during SwitchToFrame? Why the execution context did not change after switched to new frame?

The  frameNavigated, frameStartedLoading, frameStoppedLoading, and executionContextXxx are Events. Chrome reports them to ChromeDriver, and some are explicitly used to determined the loading state of the current frame. They occur as a result of other browser interactions - if a click requires a new frame to be created, then those events will be fired. SwitchToFrame is a Command issued by ChromeDriver; it doesn't initiate frame creation, though it will try to wait for the requested frame to load. If that frame's context is destroyed, ChromeDriver can't determine the navigation state, and will timeout or error out, depending on the exact point of the destruction.