The case - I can get access to my AUT only from my company's virtual machine, connecing to it by RDP.
I'm using jmeter's jsr223 samples to create the load by means of a chromedriver (interacting with it by org.openqa.selenium methods, sending the instructions by http requests to localhost).
If i don't add chromedriver.addOptions("--headless")
so that chromedriver actually opens a GUI chrome window, everything works fine. However, with --headless options something goes wrong - I start the chromedriver, get.url("http://AUT/login/page")
, fill username\password fields, logging in succesfully, clicking the which opens a new window, switch to this window (I log every action, so I'm pretty sure, that until this moment everything works fine), but in this new window I'm trying to perform element.sendKeys
(which works ok in 99.9% cases in GUI mode) but, get a timeout exception (actually using wait.until(ExpectedConditions.ElementToBeClickable(By.xpath('//bla-bla/bla'))).sendKeys("zzzz");
) and always get a timeout exception.
When I log the hole document's innerHTML, I can clearly see that //input i'm trying to access is present in the document.
Also tried to launch the --headless variant from my colleagues local machine (which also has access to AUT hosts) - everything works fine. However I'll have to generate the load from hosts, accessed by RDP, and if the headless mode won't work on it, I'll be fired&killed (:. So can anyone please tell me, which group policies in Win7 can affect the headless chromedriver work?
Also I had to add ChromeOptions.setExpirementalOption("useAutomationExtension",false)
because without it, (even in non-headless mode) I get a warning box "Can't load extension from .... Loading of unpacked extensions is disabled by the administrator"
However, after clicking OK in this warning, the test continues without any problem.
It seems, that I'll have to require some special Windows group policy modifications from my companies SysAdmins && security service for the success.