Exposing the PID of the browser process from the remote end to the local end - in Capabilities?

Hi!

We'd love to be able to get the main PID of the browser process back from WebDriver implementations (like chromedriver) in order to test the exposed accessibility API on the browser. We need the PID in order to reliably find the the accessibility API of the browser through the platform's accessibility API (otherwise, we would have to find the application by name, which is tricky if there are more than one Firefoxes open). We only need the main PID of the browser in all cases.

We'd like to get this information from WebDriver implementations like chromedriver specifically because it would allow us to use WebDriver in our test suite. We would use WebDriver to start the browser, load test pages, and interact with the browser (like clicking buttons or running scripts), then separately query the browser through the accessibility API.

For some context: accessibility APIs are what assistive technologies like screen readers use to interact with applications like web browsers. We are working on extending WPT with tests that test the html -> accessibility API mappings. If you are curious to understand more, you can read this explainer from my colleague @alice: https://github.com/Igalia/wpt/blob/explainer/docs/wpt-for-aams.md

I'm new to reading the WebDriver spec, but it seems to me that a process ID can be returned in the Capabilities object returned when starting a new Session. This might not makes sense to do when using WebDriver over a network. In our case, we can only query the accessibility API of a browser on the same local machine.

So my questions:

• Can we return the PID in the Capabilities object?
• Is there a better way to return the PID (like through a request)?
• Is it ok to specify to return the PID only if the Session request came from localhost?

Looking at the code for the chromedriver implementation, I think this won't be hard to do, and I would be happy to supply a patch if this change is supported! :)

Start with the WebDriver specification's Capabilities object and new-session flow, then compare the chromedriver implementation mentioned in the issue. Review the linked WPT accessibility explainer for the testing context. Done would require an agreed, interoperable way to expose the browser PID, including its behavior for local and remote sessions.