Closed Bug 1282873 Opened 8 years ago Closed 7 years ago

Look for proxy settings in both required- and desired capabilities sets

Categories

(Remote Protocol :: Marionette, defect)

Version 3
defect
Not set
normal

Tracking

(firefox52 fixed, firefox53 fixed)

RESOLVED FIXED
mozilla53
Tracking Status
firefox52 --- fixed
firefox53 --- fixed

People

(Reporter: ato, Assigned: ato)

References

(Blocks 1 open bug)

Details

According to https://github.com/mozilla/geckodriver/issues/97#issuecomment-229129641 Marionette only looks for the proxy settings in the requiredCapabilities field.  It should also look in the desiredCapabilities field.

https://dxr.mozilla.org/mozilla-central/source/testing/marionette/driver.js#601
Blocks: webdriver
The reason it was placed in requiredCapabilities is that it is near impossible to check that the proxy settings are working the end user. Historically, if the proxy settings are there people are actually wanting them to be used or to fail.


Moving forward, I wonder if this is something that would be better suited in the like browser :{} capabilities at the top of the capabilities object.
I'm not sure I understand that argument. If it's not possible to check that the settings are working, then how do you know whether the required capability was fulfilled? That seems equally impossible, regardless of the strength of the end user's desire.

There are a lot of tests in the wild that put proxy settings in the desired capabilities, even though they really mean to "require" the proxy. That could be out of unfamiliarity with the distinction, or because of a lack of local end support for required caps. It would be nice for those to keep working one way or another.
If the UA fails to set the proxy in a desiredCapabilities world, with errors from the UA, it will fail silently and in a requiredCapabilities world it would pass back those errors.
The conclusion from IRC is that we don't actually return the "proxy" capability in the new session response. I thought we did, but that's not the case, so there isn't any way to indicate that the proxy capability was not fulfilled.
I don’t think we should check if the proxy settings work when it is provided.  This feels like another case where the desired vs. required capability distinction doesn’t make any sense.  The purpose of capabilities is, primarily, to select a browser configuration from a matrix; not to filter at the driver level what features are enabled or not.  C.f. jgraham’s mail on the mailing list about shared browser configuration options.
Assignee: nobody → ato
Status: NEW → ASSIGNED
I’ve started work on this.  Unfortunately I need to rewrite large portions of the capabilities processing steps to do this patch, but we needed to do that at some point anyway.
Depends on: 1326534
Status: ASSIGNED → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla53
Product: Testing → Remote Protocol
You need to log in before you can comment on or make changes to this bug.