Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add a capability for returning the main PID of the browser #1833

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

spectranaut
Copy link

@spectranaut spectranaut commented Jul 23, 2024

Closes #1823

As discussed in the issue, returning the main PID of the browser will allow us to do accessibility testing of platform accessibility APIs exposed by the browser. Otherwise, we have to rely on the browser name, which is less reliable.

This value obviously cannot be used for matching and only is an returned value.

It doesn't look like there is precedent for this, but I wonder if this should be optional capability, in case there is a reason to no return the PID?


Preview | Diff

@@ -2009,6 +2016,9 @@ <h3>Processing capabilities</h3>

<dt>"<code>userAgent</code>"
<dd>String containing the <a>default User-Agent value</a>.

<dt>"<code>processID</code>"
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For example, this could be:

Suggested change
<dt>"<code>processID</code>"
<dt>"<code>processID</code> (optional)"

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right; do we want to say anything here about suggesting that the processID be included iff the client is on localhost?

@spectranaut
Copy link
Author

@whimboo and @gsnedders -- can you review this change based on our discussion? :)

Copy link
Member

@jgraham jgraham left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This PR is currently only affecting the non-normative parts of the spec. To actually return a value in capabilities you need to set it in the matching capabilities algorithm.

@spectranaut
Copy link
Author

This PR is currently only affecting the non-normative parts of the spec. To actually return a value in capabilities you need to set it in the matching capabilities algorithm.

Ah thanks @jgraham for pointing this out. I was wondering myself about that, but I looked at the previous capability added (#1790) and it also didn't update the matching algorithm. I wonder what the point of this previous PR was? Did it also make a mistake?

I also have a question -- and sorry if it's a silly one, I've only used webdriver minimally -- it seems to me, according to matching capabilities step 4 and later, the returned capabilities seems to only include keys that were specifically set in the new session command? Is that true?

I'm pretty sure that returning the PID should be optionally, and isn't not need and shouldn't be returned in all cases. So I'm trying to wrap my head around how to "optionally" return the PID. The other option is to use a extension capabilities to do this, like firefox does, returning "moz:processID".

@gsnedders
Copy link
Member

Ah thanks @jgraham for pointing this out. I was wondering myself about that, but I looked at the previous capability added (#1790) and it also didn't update the matching algorithm. I wonder what the point of this previous PR was? Did it also make a mistake?

The addition at lines 2011–3 does that, as that is within the matching algorithm.

#1792 is related here (don't expect you to solve this, just want the cross-reference!).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

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