-
Notifications
You must be signed in to change notification settings - Fork 58
Description
This doesn't seem to be a regression in the code, but rather something that only occurs sometimes under certain conditions. From what I can tell, it's an issue with the ChromeDriver itself: When the page that is used to retrieve the default WebDriver headers is served by Selenium Requests and then immediately closed by the JavaScript snippet, the code execution sometimes freezes in the subsequent callback where the current URL is requested, after switching to the already closed window handle in the find_window_handle method. This shouldn't happen; instead a NoSuchWindowException should be raised immediately by the WebDriver which the module would and can handle.
I'm not sure how to fix this yet, and adding ChromeDriver-specific code or artificial wait times seems like a rather bad solution. I reported this bug to the ChromeDriver bug tracker. If you want it to be fixed in a proper manner, maybe star the issue and thus highlight its importance.