Since Geckodriver 0.31, it's no longer possible to pass capability --remote-debugging-port

[Tyoneb]

System

• Version: 0.31.0
• Platform: Windows 10 (64b)
• Firefox: 99.0.1 (64b)
• Selenium: None

Testcase

1. start geckodriver:

geckodriver.exe -p 4444

2. Using a REST HTTP client, create a new session and pass the capabilities to set --remote-debugging-port (code sample using VS Code REST Client extension):

POST http://locahost:4444/session

{
  "desiredCapabilities": {
    "moz:firefoxOptions":{
      "args":["--remote-debugging-port=4445"]
    }
  }
}

Additional remarks

• Same behavior is observed with the new way of passing capabilities (using alwaysMatch)
• Option --remote-debugging-port is still recognized by Firefox executable, at least until v99
• Passing capability moz:debuggerAddress as documented here does not provide additional information in the returned capabilities to retrieve the debug port

Stacktrace

{
  "value": {
    "error": "invalid argument",
    "message": "Argument --remote-debugging-port can't be set via capabilities",
    "stacktrace": ""
  }
}

Expected

Session creation with the specified remote debugging port opened which allows to call /json/version in order to retrieve the webSocketDebuggerUrl.

This used to work until Geckodriver 0.30.0.

If this behavior is intended, there is no mention of the change in the 0.31.0 release notes . In which case, an acceptable bypass would be to provide another way of setting the debug port or retrieving its value if it is automatically set.

[whimboo]

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.

[Tyoneb]

@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
    }
  }
}

Response

{
  "value": {
    "sessionId": "3b42b163-6c32-4adb-83a7-53888f98f582",
    "capabilities": {
      "acceptInsecureCerts": false,
      "browserName": "firefox",
      "browserVersion": "99.0.1",
      "moz:accessibilityChecks": false,
      "moz:buildID": "20220411174855",
      "moz:geckodriverVersion": "0.31.0",
      "moz:headless": false,
      "moz:processID": 46644,
      "moz:profile": "C:\\Users\\XXXXX\\AppData\\Local\\Temp\\rust_mozprofilehfAlFA",
      "moz:shutdownTimeout": 60000,
      "moz:useNonSpecCompliantPointerOrigin": false,
      "moz:webdriverClick": true,
      "pageLoadStrategy": "normal",
      "platformName": "windows",
      "platformVersion": "10.0",
      "proxy": {},
      "setWindowRect": true,
      "strictFileInteractability": false,
      "timeouts": {
        "implicit": 0,
        "pageLoad": 300000,
        "script": 30000
      },
      "unhandledPromptBehavior": "dismiss and notify"
    }
  }
}

New capabilities:

POST http://localhost:4444/session

{
  "capabilities": {
    "alwaysMatch": {
      "moz:debuggerAddress": true
    }
  }
}

Response

{
  "value": {
    "sessionId": "05eb8a11-c177-453f-abd4-0f5300479405",
    "capabilities": {
      "acceptInsecureCerts": false,
      "browserName": "firefox",
      "browserVersion": "99.0.1",
      "moz:accessibilityChecks": false,
      "moz:buildID": "20220411174855",
      "moz:debuggerAddress": "localhost:9222",
      "moz:geckodriverVersion": "0.31.0",
      "moz:headless": false,
      "moz:processID": 33272,
      "moz:profile": "C:\\Users\\XXXXX\\AppData\\Local\\Temp\\rust_mozprofilexTZfk3",
      "moz:shutdownTimeout": 60000,
      "moz:useNonSpecCompliantPointerOrigin": false,
      "moz:webdriverClick": true,
      "pageLoadStrategy": "normal",
      "platformName": "windows",
      "platformVersion": "10.0",
      "proxy": {},
      "setWindowRect": true,
      "strictFileInteractability": false,
      "timeouts": {
        "implicit": 0,
        "pageLoad": 300000,
        "script": 30000
      },
      "unhandledPromptBehavior": "dismiss and notify"
    }
  }
}

Am I doing this wrong? Or do I need to pass an additional capability?

[whimboo]

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.

[Tyoneb]

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!

[whimboo]

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

[Tyoneb]

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!

[asambstack]

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.

[whimboo]

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.

[asambstack]

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?

[whimboo]

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

[asambstack]

Cool, no worries
Thanks for your time!

[christian-bromann]

@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?

[whimboo]

@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.

[christian-bromann]

I am talking about moz:debuggerAddress. I guess it will be deprecated anyway at some point.

[whimboo]

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.

[christian-bromann]

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!