TypeError: browsingContext.currentWindowGlobal is null

jsnjack commented 1 year ago

System

Version: 0.33.0
Platform: Linux
Firefox: 113.0.1
Selenium: 4.9.0

Testcase

Since firefox released v113 we have been having a lot of problems with the test stability. It seems that firefox loses the reference to window object. Our logs are full of the following log messages TypeError: browsingContext.currentWindowGlobal is null

Code that fails often:

wd.get(link)
WebDriverWait(wd, 15).until(
  EC.presence_of_element_located((By.CSS_SELECTOR, selector))
)

We developed a "workaround" for this issue:

wd.get(link)
sleep(1)
WebDriverWait(wd, 15).until(
  EC.presence_of_element_located((By.CSS_SELECTOR, selector))
)

Stacktrace

(wd) Message: TypeError: browsingContext.currentWindowGlobal is null
Stacktrace:
getMarionetteCommandsActorProxy/get/<@chrome://remote/content/marionette/actors/MarionetteCommandsParent.sys.mjs:309:29
GeckoDriver.prototype.takeScreenshot@chrome://remote/content/marionette/driver.sys.mjs:2471:26

selenium.common.exceptions.NoSuchWindowException: Message: Browsing context has been discarded
Stacktrace:
RemoteError@chrome://remote/content/shared/RemoteError.sys.mjs:8:8
WebDriverError@chrome://remote/content/shared/webdriver/Errors.sys.mjs:183:5
NoSuchWindowError@chrome://remote/content/shared/webdriver/Errors.sys.mjs:468:5
assert.that/<@chrome://remote/content/shared/webdriver/Assert.sys.mjs:485:13
assert.open@chrome://remote/content/shared/webdriver/Assert.sys.mjs:147:4
GeckoDriver.prototype.findElement@chrome://remote/content/marionette/driver.sys.mjs:1495:15
despatch@chrome://remote/content/marionette/server.sys.mjs:304:40
execute@chrome://remote/content/marionette/server.sys.mjs:275:16
onPacket/<@chrome://remote/content/marionette/server.sys.mjs:248:20
onPacket@chrome://remote/content/marionette/server.sys.mjs:249:9
_onJSONObjectReady/<@chrome://remote/content/marionette/transport.sys.mjs:496:20

Trace-level log

whimboo commented 1 year ago

Could you please attach a trace-level log from geckodriver? Read more about reporting actionable bugs in our contribution guidelines.

jsnjack commented 1 year ago

Sure, I attached them to this message 1684340071071 Marionette.txt

whimboo commented 1 year ago

It's not clear to me what's happening on this site - maybe you can help. As it looks like an iframe is getting added by the navigation and that you switch to that frame. Then when trying to find an element it fails initially because it is added lazily to the DOM? Surprisingly then the iframe gets destroyed and the find element call fails as expected with no such window. But then a screenshot seems to be taken and it fails with the unknown error instead of no such window.

So I have two questions:

What closes the iframe? Is that on purpose and done by the page?
Does that only happen for the WebDriver:TakeScreenshot command or other commands affected as well in not correctly reporting no such window?

whimboo commented 1 year ago

I can actually see the failure when the currently selected frame is removed before taking a screenshot. This is because we inappropriately try to screenshot the child browsing context but not the top-level one as given by the spec. There is bug 1493650 which covers that.

Nevertheless I would be still interested to see what's going on for this page and why the iframe is getting removed.

jsnjack commented 1 year ago

We have many tests which follow the following pattern

we do wd.get(<url>), it loads the main page which has the iframe with the following selector [name=_surfly_tab0]
we wait for this element to be present on the page, when it is found we switch to it and wait for body > h1 element inside this iframe
if the test fails, we make a screenshot

Reading the logs again, after your comment, I think that the problem is indeed in [name=_surfly_tab0] iframe being removed.

Adding sleep(1) solves the problem because, I think, the iframe is recreated in this short period? :thinking:

We run the same test also in Chrome and it doesn't have this iframe create/remove/create problem.

Switching to the default context will fix the screenshot problem, but it seems the the real problem is the iframe.

jsnjack commented 1 year ago

Was able to track it to our frontend framework, which deletes and creates iframe in a very short period of time. Not sure what made the problem more "obvious" in Firefox 113, but it is the problem on our side!

Thanks for the help!

whimboo commented 1 year ago

Good to know and thanks for the remaining investigation. Basically all the other commands beside taking a screenshot should work given that those use the correct browsing context check. Only the screenshot command is broken and we are still going to fix that via bug 1493650.

mozilla / geckodriver