Switch Window sporadically fails with TypeError

[Mercury37]

Observed with

Python 3.13.0
SeleniumLibrary 6.7.1

Scenario

I have the following scenario in a test which fails sporadically:

1. Link in an (internal) application is clicked which opens a different URL in a new tab
2. Switch Window is called with the expected URL as locator and 10 s as a timeout

Expected behaviour

The new window is switched to. If the window is not immediately available/ready when this keyword is started, it should wait until the window can be switched to, within the given timeout limits.

Error

This works just fine most of the time, but occasionally I get the following error:
TypeError: cannot unpack non-iterable NoneType object
This error shows up pretty much instantly (within a few hundred ms), so the timeout is not taken into account.
However, in the associated screenshots, the expected page is always shown.

Analysis

I looked into the library's code and added some extra logging, which showed the error was coming from this line:

SeleniumLibrary/src/SeleniumLibrary/locators/windowmanager.py

Line 199 in ce9d0ec

id, name = self.driver.execute_script("return [ window.id, window.name ];")

The call to self.driver.execute_script("return [ window.id, window.name ];") returns None, thus the assignment to the two variables fails with the above error.

Adding a 1 s sleep right before the call to execute_script makes the error no longer occur (even with many iterations of the test), so it does seem to be somehow timing related.
I guess there's a short timeframe where the window is there but not fully ready and this makes the function call fail? But I wasn't able to understand the exact nature of this presumed 'not ready' state so far.

Proposed solution

The TypeError could be added to the already present except, which successfully avoided failures due to this in my scenario.
Adding this would be trivial, but I'm not sure about the implications:

• does anything depend on the current behaviour that raises an error in this case (seems not, but I'm not super familiar with the library's codebase)?
• would it be appropriate to suppress this error in the library, given it is not fully understood what exactly the nature of the actual, underlying error is?
  Do you have any guidance how to proceed here?

[Mercury37]

I managed to dig a bit a deeper into this issue and found that the issue appears to be specific to Firefox/geckodriver. I have not been able to reproduce it in Chrome.

Activating trace logs for geckodriver reveals the following:

1772546742849	webdriver::server	DEBUG	-> POST /session/1a0a34ad-c264-48a4-be08-f886f3b15996/window {"handle": "ac1bbb9e-1fb5-4838-b1e0-0c5cb630dcca"}
1772546742852	Marionette	TRACE	[15032385540] MarionetteCommands actor destroyed for window id 15032385549
1772546742853	Marionette	DEBUG	0 -> [0,494,"WebDriver:SwitchToWindow",{"handle":"ac1bbb9e-1fb5-4838-b1e0-0c5cb630dcca"}]
1772546742861	RemoteAgent	TRACE	Received DOM event activate for [object Window]
1772546742861	RemoteAgent	TRACE	Received DOM event focus for [object HTMLDocument]
1772546742864	Marionette	DEBUG	0 <- [1,494,null,{"value":null}]
1772546742865	webdriver::server	DEBUG	<- 200 OK {"value":null}
1772546742866	webdriver::server	DEBUG	-> POST /session/1a0a34ad-c264-48a4-be08-f886f3b15996/execute/sync {"script": "return [ window.id, window.name ];", "args": []}
1772546742867	Marionette	DEBUG	0 -> [0,495,"WebDriver:ExecuteScript",{"args":[],"script":"return [ window.id, window.name ];"}]
1772546742875	Marionette	TRACE	[15032385540] Querying "executeScript" failed with AbortError, returning "null" as fallback

The call to execute script seems to be precisely what is causing the failure in the SeleniumLibrary, as the call returns null which fails to be assigned to id, name.
I think this matches the following marionette bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1673478
But if I understand correctly they are waiting for an update of the webdriver spec regarding which error to raise?

Given this, does it make sense for the SeleniumLibrary to handle the possibility of execute_script returning None more gracefully?