SeleniumLibrary
SeleniumLibrary copied to clipboard
Switch window timing out when used in combination with Chrome headless mode
Steps to reproduce the issue
I have a test that opens an PDF file in the web browser. This scenario runs perfectly when I don't use Chrome's headless mode. As soon I pass the argument so it opens in headless mode, the keyword Switch Window doesn't work. The keyword stays "running" for 10 minutes until the session timeout.
My test scenario is this:
Login Access
Click ${pageHome.openMenu}
Click ${pageHome.openProfile}
Scroll Down Window To Element ${pageProfile.linkContract}
Click ${pageProfile.linkContract}
Switch Window url:https://drive.conqueronline.com.br/CONTRATO_MULTIPERFIS.pdf
Location Should Be https://drive.conqueronline.com.br/CONTRATO_MULTIPERFIS.pdf
Obs: The URL it is public.
My suite_setup.robot is set this way:
*** Settings ***
Library SeleniumLibrary
Library String
Library Collections
Library OperatingSystem
Library DateTime
Library FakerLibrary locale=pt_BR
*** Variables ***
${HEADLESS}= ${HEADLESS}
${TEARDOWN}= True
${URL}= ${URL}
${FAST_TIMEOUT}= 5
${TIMEOUT}= 30
${LONG_TIMEOUT}= 60
${HARD_TIMEOUT}= 90
*** Keywords ***
Open Browser
${CHROME_OPTIONS}= Evaluate sys.modules['selenium.webdriver'].ChromeOptions() sys, selenium.webdriver
Call Method ${CHROME_OPTIONS} add_argument --incognito
Call Method ${CHROME_OPTIONS} add_argument --disable-notifications
Call Method ${CHROME_OPTIONS} add_argument --new-window
Call Method ${CHROME_OPTIONS} add_argument --aggressive-cache-discard
Call Method ${CHROME_OPTIONS} add_argument --disable-application-cache
Call Method ${CHROME_OPTIONS} add_argument --disable-dev-shm-usage
Call Method ${CHROME_OPTIONS} add_argument --no-sandbox
Call Method ${CHROME_OPTIONS} add_argument --disable-gpu
Call Method ${CHROME_OPTIONS} add_argument --mute-audio
Call Method ${CHROME_OPTIONS} add_argument --start-maximized
Run Keyword If ${HEADLESS}==True With Headless ${CHROME_OPTIONS}
Run Keyword If ${HEADLESS}==False Without Headless ${CHROME_OPTIONS}
With Headless
[Arguments] ${CHROME_OPTIONS}
Call Method ${CHROME_OPTIONS} add_argument --headless
Open Browser ${URL} chrome options=${CHROME_OPTIONS}
Set Window Size 1920 1080
Without Headless
[Arguments] ${CHROME_OPTIONS}
Open Browser ${URL} chrome options=${CHROME_OPTIONS}
Error messages and additional information
This is the error I get after 10 minutes:
TimeoutException: Message: timeout: Timed out receiving message from renderer: 300.000
(Session info: headless chrome=113.0.5672.129)
Stacktrace:
Backtrace:
GetHandleVerifier [0x00498893+48451]
(No symbol) [0x0042B8A1]
(No symbol) [0x00335058]
(No symbol) [0x003282BF]
(No symbol) [0x0032810C]
(No symbol) [0x00326D46]
(No symbol) [0x003275CA]
(No symbol) [0x00330135]
(No symbol) [0x0033C2B8]
(No symbol) [0x0033F1B6]
(No symbol) [0x003279E3]
(No symbol) [0x0033C189]
(No symbol) [0x0038C3DD]
(No symbol) [0x0037A0B6]
(No symbol) [0x00357E08]
(No symbol) [0x00358F2D]
GetHandleVerifier [0x006F8E3A+2540266]
GetHandleVerifier [0x00738959+2801161]
GetHandleVerifier [0x0073295C+2776588]
GetHandleVerifier [0x00522280+612144]
(No symbol) [0x00434F6C]
(No symbol) [0x004311D8]
(No symbol) [0x004312BB]
(No symbol) [0x00424857]
BaseThreadInitThunk [0x765F00C9+25]
RtlGetAppContainerNamedObjectPath [0x77107B4E+286]
RtlGetAppContainerNamedObjectPath [0x77107B1E+238]
I tried using some kind of debug to see if the new tab is being open but the keywork also stop working after I click to open the PDF file. I tried using Get Window Titles, Get Window Handles and Get Window Identifiers. This 3 keywords had the same problem, stayed running for 10 minutes then the session timeout.
Environment
Browser: Google Chrome | Version=113.0.5672.129 Browser driver: Chromedriver.exe | Version=113 Operating System: Windows 10 22H2 Libraries
- Robot Framework: 6.0.2
- Selenium: 4.9.0
- Selenium Library: 6.1.0
So as I do every time an issue comes up that I personally don't have a clue about, I'll google it. I have two sources I would start with. The first is this Stack Overflow answer. Now specifically choosing out this search result over the other because a personal sense of confidence projected by the author I was also being a bit cautious to the claim that "up to date from every issue ever reported on stack overflow as of: September 2018" (in italics and bold no less :) ) I wanted to see what was newer. So narrowed the google search to the past month and got this second response.
My guess would be the secret sauce - or at least the first I would try to got the right Chrome options. I think the first source says it right when they say,
what I like to call the "Ever Growing List of Useless Arguments" chromedriver requires
That said throwing Windows in as part of the configuration always complicates answers .. or at least to me.
Closing issue due to lack of activity. If this is still an issue please reopen and I will take another look.