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

Already on GitHub? Sign in to your account

Using desired_capabilities affects future sessions #217

ombre42 opened this Issue Jun 25, 2013 · 2 comments


None yet
1 participant

ombre42 commented Jun 25, 2013

When desired_capabilities is passed to Open Browser, the default DesiredCapabilities object for the requested browser (which is a class attribute) is changed for the remainder of the test run. Unfortunately, the Selenium project's examples for Python demonstrate doing it that way.
I will submit a pull request to address this issue.
If instead we took a copy of the default desired capabilities object and manipulated that, this would not be an issue. A deep copy would safeguard against default capabilities with nested dicts.

In the following set of test cases, Second will use the proxy setup in First, even if they reside in different suites. You can see this in the output of Open Browser in Second if you run with log level DEBUG:
20130625 16:49:20.017 : DEBUG : POST {"sessionId": null, "desiredCapabilities": {"platform": "ANY", "browserName": "chrome", "version": "", "proxy": {"proxyType": "MANUAL", "httpProxy": "localhost:8888"}, "javascriptEnabled": true}}

    ${chrome dc}=    Evaluate    selenium.webdriver.DesiredCapabilities.CHROME    selenium
    Dictionary Should Not Contain Key    ${chrome dc}    proxy
    ${desired capabilities}=    Evaluate    {'proxy': {'proxyType': 'MANUAL', 'httpProxy': 'localhost:8888'}}
    Open Browser    http://www.google.com/    gc    remote_url=http://localhost:4444/wd/hub    desired_capabilities=${desired capabilities}
    [Teardown]    Close Browser

    ${chrome dc}=    Evaluate    selenium.webdriver.DesiredCapabilities.CHROME    selenium
    Run Keyword And Continue On Failure    Dictionary Should Not Contain Key    ${chrome dc}    proxy
    Open Browser    http://www.msn.com/    gc    remote_url=http://localhost:4444/wd/hub
    [Teardown]    Close Browser

ombre42 commented Dec 28, 2013

This may be fixed upstream. Selenium team is considering returning a copy of the desired capabilities dict in this issue. Since this issue was discovered in code analysis and not reported by users and may be fixed upstream, moving to 1.6.


ombre42 commented Dec 29, 2013

Looks like Selenium team thinks users should work with a copy of the desired capabilities. Since a Selenium2Library user does not really have a choice, we should always work with a copy. If a capability is required in every browser opened in the same session, then is must be specified in every call to Open Browser.

@ombre42 ombre42 closed this in 4586aee Dec 31, 2013

emanlove added a commit that referenced this issue Dec 31, 2013

Merge pull request #258 from ombre42/master
fixes #217 - copy desired capabilities before modifying
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment