Closed Tyoneb closed 2 years ago
There is no mentioning of this change in the release notes because basically no-one should actually pass this Firefox argument through capabilities. Instead the moz:debuggerAddress
capability has to be set for the New Session
command. Within the returned capabilities you can find the same capability again, which then contains the wanted host and port of the CDP WebSocket address.
Note that CDP support for Firefox is already in Selenium since version 4.0, and that still works as expected by using this capability.
@whimboo, thanks for the quick reply. I understand that it is an intended behavior, however as I was mentioning in my initial post, what is documented does not seem to work: when I pass the moz:debuggerAddress
capability, there is no such capability in the response.
Note that I'm not using any Selenium server, I'm calling directly the geckodriver Webdriver server.
You can reproduce it very easily with the following:
Legacy capabilities:
POST http://localhost:4444/session
{
"desiredCapabilities": {
"moz:firefoxOptions": {
"moz:debuggerAddress": true
}
}
}
New capabilities:
POST http://localhost:4444/session
{
"capabilities": {
"alwaysMatch": {
"moz:debuggerAddress": true
}
}
}
Am I doing this wrong? Or do I need to pass an additional capability?
For capability matching you should use alwaysMatch
or firstMatch
. Given your second example I can see "moz:debuggerAddress": "localhost:9222"
in the response's payload.
Hum, quite embarrassing... I don't understand how I missed it! Thanks a lot for your support and sorry for wasting your time on this!
No worries at all. Good to see that it's working as expected for you now. Note that soon WebDriver BiDi will also be a thing in case you are interested in. Feel free to drop into our Matrix channel at https://chat.mozilla.org/#/room/#webdriver:mozilla.org
Yes, I'm well aware, can't wait to have a standardized way of using those DevTools. A websocket will definitely be a major improvement upon the current REST-based implementation. And I'm really glad that all major browsers appear around that virtual spec table as well...! I'm afraid I don't have the time nor the expertise to participate in geckodriver's implementation but I'll definitely keep track of the announcements. Good luck!
Hey @whimboo
Could you tell me how we can pass in a customised host:port for selenium webdriver with geckodriver 0.31.0
? Since moz:debuggerAddress
is a bool, I'm not able to find any docs on how we can pass in customised host:port as our debugger address.
I'm using the following caps with selenium-3.141.59 JAR and geckodriver 0.31.0
let capabilities = {
'browserName' : 'firefox',
"alwaysMatch": {
"moz:debuggerAddress": true // " how can I use localhost:9001?"
},
'moz:firefoxOptions': {
"args": [
// "--remote-debugging-port=9222",
"--no-remote",
"--foreground",
"--wait-for-browser"
]
}
}
Let me know if I'm making some mistake in the caps.
The geckodriver binary supports the --websocket-port
argument. By default the port 9222
will be used but you can also set to some other number or even 0
for a system allocated port.
Thanks for the quick response! I'm not spawning geckodriver binary directly and rather using selenium with 0.31.0
geckodriver.
Could you tell me how I can set it through selenium caps?
I would suggest that you consult the documentation of the corresponding Selenium binding or ask their community support. It's outside of my knowledge which APIs different Selenium bindings actually offer. Sorry
Cool, no worries Thanks for your time!
@whimboo it seems difficult to type this capability given it is a boolean
when send as session capability request but is returned as string
. Are there plans to make this a bit less ambiguous?
@christian-bromann which capability are you referring to? The webSocketUrl
one? Having to set this as a boolean is required by the spec, and there are no plans yet to change that. Bug feel free to file an issue if you think it needs to be discussed.
I am talking about moz:debuggerAddress
. I guess it will be deprecated anyway at some point.
Yes, and this will be hopefully soon. For which features do you still need CDP via Selenium? AFAIK logging (which was the only used CDP feature with Firefox) is now completely done via WebDriver BiDi.
I was just fixing a bug in WebdriverIO where someone reported that WDIO wouldn't recognise that capability. I let them know that it will be deprecated. Thanks for the info!
System
Testcase
--remote-debugging-port
(code sample using VS Code REST Client extension):{ "desiredCapabilities": { "moz:firefoxOptions":{ "args":["--remote-debugging-port=4445"] } } }
{ "value": { "error": "invalid argument", "message": "Argument --remote-debugging-port can't be set via capabilities", "stacktrace": "" } }