-
Notifications
You must be signed in to change notification settings - Fork 195
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
base: master
Are you sure you want to change the base?
Conversation
@@ -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>" |
There was a problem hiding this comment.
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:
<dt>"<code>processID</code>" | |
<dt>"<code>processID</code> (optional)" |
There was a problem hiding this comment.
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?
7973df4
to
172882a
Compare
@whimboo and @gsnedders -- can you review this change based on our discussion? :) |
There was a problem hiding this 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.
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". |
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!). |
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