When trying to automate one of the webrtc use case via selenium in chrome-headless mode,
I configured following options:
caps := selenium.Capabilities{"browserName": "chrome"}
chromePrefs := make(map[string]interface{})
chromePrefs["profile.default_content_setting_values.media_stream_mic"] = 1
chromePrefs["profile.default_content_setting_values.media_stream_camera"] = 1
chromeCaps := chrome.Capabilities{
Path: "",
Args: []string{
"--ignore-certificate-errors",
"--use-fake-device-for-media-stream",
"--use-fake-ui-for-media-stream",
"--headless",
"--no-sandbox",
"--disable-dev-shm-usage",
},
Prefs: chromePrefs,
}
caps.AddChrome(chromeCaps)
Here I am just using golang selenium wrapper from https://github.com/tebeka/selenium which is over original java driver
So the observation is
in GUI mode(without headless) chrome is generating ice candidate for all the interfaces in my PC and
it connects well with remote peer
In Headless mode, it generates only 1 ICE candidate with type host with mdns example:392f939d-6507-45e1-87da-19b63fb76a9e.local and not anymore and ice connection is failing as remote peer I am using is in not compatible to parse mdns
To overcome I added a STUN server support with peerconnection configured to use example
var peerConnectionConfig = { 'iceServers': [{ 'url': 'stun:192.189.67.565:3478' }], 'bundlePolicy': 'max-bundle'};
And I can clearly see via wireshark, STUN Binding Request is sent and successful mapped Binding Success Response address(192.185.46.57) is sent in return, but its not used by chrome to generate additional ice candidates in this headless mode
I would like to know is there any additional/different configuration essential for chrome-webrtc-ice connections to work when using in headless mode?
Thanks
preference is not supported for headless browser
As of Feb , 2021
https://bugs.chromium.org/p/chromedriver/issues/detail?id=1925
Headless chrome doesn't support preferrences setting . You can use command line arguments only.
the full list of supported arguments are :
https://peter.sh/experiments/chromium-command-line-switches/
Here you can see --blink-settings so ,
try
chrome_options.add_arguments('--use-file-for-fake-audio-capture=random_audio.wav')
chrome_options.add_arguments('--use-file-for-fake-video-capture=random_audio.y4m')
I don't think it works, I have tried it for myself. I believe it is this issue:
https://bugs.chromium.org/p/chromium/issues/detail?id=776649
The application I am testing confirms my suspicion in the logs:
2021-02-31 17:27:19.240 Available media devices:
2021-02-31 17:27:19.241 : audioinput
2021-02-31 17:27:19.241 : videoinput
2021-02-31 17:27:19.241 : audiooutput
2021-02-31 17:27:19.256 Local media is not present NotSupportedError: Not supported
2021-02-31 17:27:19.256 No local media configured
Related
Background: Here is my situation, I have a website I access that requires me to go through a proxy. For day-to-day use, I installed the chrome extension Proxy switchyomega to switch between proxies based on a URL wildcard. For example, when I go to URL abc.xyz.com my company requires me to use a proxy at x.x.x.x:yyyy.
Issue I am trying to write an automation script using WebdriverIO (version 7.24.0) in standalone mode using chrome that will launch the website abc.xyz.com. The problem is when I run the script it is not going through the proxy, so my access is blocked. I have tried to configure a proxy in the capabilities but that does not seem to work, and I'm wondering if I'm doing something wrong in my configuration, which is below
const { remote } = require("webdriverio");
const browser = await remote({
capabilities: {
browserName: "chrome",
proxy: {
proxyType: "manual",
httpProxy: "x.x.x.x:yyyy"
}
},
});
await browser.url("abc.xyz.com");
As mentioned in normal use when I access URL abc.xyz.com it routes through the x.x.x.x:yyyy proxy and that is what I need to happen when running my script but the above configuration does not seem to do anything.
Any help would be appreciated.
I am using Selenium with ChromeDriver in .NET Core. All tests work fine locally, however fail in TeamCity with the following error:
Starting ChromeDriver 80.0.3987.106 (f68069574609230cf9b635cd784cfb1bf81bb53a-refs/branch-heads/3987#{#882}) on port 24272
Only local connections are allowed.
Please protect ports used by ChromeDriver and related test frameworks to prevent access by malicious code.
...
OneTimeSetUp: OpenQA.Selenium.WebDriverException : Cannot start the driver service on http://localhost:24272/
After the tests have finished, chromedriver.exe isn't terminated. There is nothing in the Windows event log or further details in the build logs, so I'm now stabbing in the dark.
I am using the following arguments, some added out of desperation:
var options = new ChromeOptions();
options.AddArgument("--headless");
options.AddArgument("--remote-debugging-port=9222");
options.AddArgument("--no-sandbox");
options.AddArgument("--no-first-run");
// See https://bugs.chromium.org/p/chromium/issues/detail?id=737678
options.AddArgument("--disable-gpu");
Driver = new ChromeDriver(options);
Interestingly, the remote debugging port != the port in the first error. Not sure if this means anything. The Chromedriver documentation suggests that options are added without leading --, but removing this doesn't seem to have any effect.
FWIW the TeamCity agent is running as a local Windows service account on Windows Server 2008 R2 (yes, I know).
When we run the script using Microsoft Edge getting the below error :
The following JSON wire protocol command endpoint is not allowed when server is running in W3C mode.
GET /shutdown
What I understand is that Edge now supports W3C mode by default. Our Java binding is sending in Json wire protocol mode(JWP). How we can instruct to Microsoft WebDriver that use JWP mode instead of W3c mode
it was mentioned in the Microsoft documentation:
w3c Use W3C WebDriver protocol (default option) 17763
jwp Use JSON Wire protocol
https://learn.microsoft.com/en-us/microsoft-edge/webdriver
Could you please let me know how we can change from W3C mode to jwp mode?
Another workaround is to specify an intermediate script for the Edge Driver which:
Invokes the actual Edge Driver executable,
passes all invocation parameters to it and
additionally adds the "jwp" parameter.
For instance, I've created a batch file edgedriver.bat with following content:
C:\Windows\System32\MicrosoftWebDriver.exe %* --jwp
And on startup of my node I specify this batch file as driver for Edge:
java -Dwebdriver.edge.driver="D:\Driver\edgedriver.bat"^
-Dwebdriver.ie.driver="D:\Driver\IEDriverServer.exe"^
-Dwebdriver.chrome.driver="D:\Driver\chromedriver.exe"^
-jar D:\Vaadin_Testbench_Node\vaadin-testbench-standalone-5.1.2.jar^
-role node^
-nodeConfig D:\Vaadin_Testbench_Node\nodeconfig.json
Try to add line below in file EdgeDriverService.java
argsBuilder.add("--jwp");
It can help web driver to launch in jwp mode.
Reference:
selenuim server node 3.14.0 failed to start new session for Edge #6464
i,m having a runtime error when i execute a webdriverIO test by console.
this is the error Couldn't connect to selenium server to execute a webdriverIO test.
I can access to my selenium server by browser (http://localhost:4444/wd/hub/static/resource/hub.html) but its still not working.
Please, can anyone help me.
thanks a lot for the help.
Have you tried this solution?
https://github.com/webdriverio/webdriverio/issues/602
Specifically, adding:
var options = {
desiredCapabilities: {
browserName: 'chrome'
},
host: 'localhost',
port: 4444
};
Worked for me.
Very long time after, but I faced this issue with Appium and I'd like to share what I find to solve it in case someone else face it with Appium.
Open Appium server application and start the server with host: 127.0.0.1 and port: 4723.
Open your Emulator or connect device.
Run again the instruction to execute it.
As per the docs:
Handling the Selenium server is out of scope of the actual WebdriverIO project.
So we need to either go with raw ChromeDriver or spin up the Selenium grid. When running with the latter and setting
WebDriver: {
url: '<your-vaue-here>',
browser: 'chrome',
host: '127.0.0.1',
port: 4444,
...
don't forget to disable the codecept.config.js section, like this:
services: [
['']
],
...
Otherwise both servers will try to use http://localhost:4444.
Caveat:
When executing codeceptJS tests in parallel via run-workers I observe flaky behaviour as some threads actually kill the Selenium grid while others are still running. To resolve this issue, disable the services section and run a dedicated Grid server as initial step in your CI pipeline (assuming this is the place you actually need the parallelism).
For testing if I am getting the relay candidates, I am using this page: http://googlechrome.github.io/webrtc/samples/web/content/peerconnection/trickle-ice/. To test from chrome 40, I provided my turn url and credentials there. After clicking gather candidates I can see no relay candidates. Doing the same test from firefox 36, I found the relay candidates. What could be the possible problem ? To further investigate the issue, I looked into wireshark log. What I found is, from firefox the stun request format includes-
STUN 146 Allocate Request UDP lifetime: 3600 user: lazy realm: with nonce
But from chrome, this is slightly different-
STUN 70 Allocate Request UDP
It seems the request code is not same. Moreover, request from chrome doesn't include the lifetime, user and realm property.
I know the question is already a bit old, however from my experience the TURN server description format (with regards to authentication) has to be formatted differently in Chrome and Firefox.
For chrome you can use:{"url": "turn:user#turn.example.com", credential:"password"},
For Firefox the format is:
{"url": "turn:turn.example.com", 'hasCredentials': true, username:"user", credential:"password"},
Maybe you can check the source to see how the turn servers are set in the example.
Edit:
Meanwhilst the format of the servers list has changed in the specification (https://www.w3.org/TR/webrtc/#rtciceserver-dictionary). Currently all implementations i know support the format:
{ "urls": ["turns:turn.example.org", "turn:turn.example.net"],
"username": "user",
"credential": "myPassword",
"credentialType": "password"
}
On Edge however it seems you need to include the query string ?transport=udp in the url.