desired_capabilities is not respected for remote browser
RyanSiu1995 opened this issue · 7 comments
Prerequisites
- I have searched for similar issues in open tickets and cannot find a duplicate.
- The issue still exists against the latest released version of SeleniumLibrary.
- This is not a usage question or support request. For those, see more details in README.rst: https://github.com/robotframework/SeleniumLibrary#support
- You are not using the Java Selenium2Library: https://github.com/MarketSquare/robotframework-seleniumlibrary-java
- Remember that this is a public forum, so remember to remove all sensitive
information, like username and password.
For issues
Steps to reproduce the issue
For selenium>4.1.3, the desired_capabilities will not be respected because of this PR.
SeleniumHQ/selenium#10494
In my case, the desired_capabilities's option will not be sent to BrowserStack to configure the browser correctly
Error messages and additional information
None of the desired_capabilities is sent to BrowserStack
Expected behavior and actual behavior
desired_capabilities should be merged to capabilities for sending to the remote webdriver.
Environment
Browser: All
Browser driver: All
Operating System: All
Libraries
- Selenium: 4.1.3+
Feature requests
We will need to handle the capabilities merging properly in order to make sure the compatibility.
Are you asking for SeleniumLibrary to handle conversion of desired_capabilities to capabilities? To me this seems like something one should do on the end user side by only using capabilities.
Either way works for me.
But I can't specify capabilities in the Open Browser keyword unfortunately.
The only supported option is desired_capabilities
Options is is the new "capabilities". Or at least that is how I am thinking about/understanding it. I'm rereading various sources and see i definitely need to review this as it is not crystal clear.
References:
https://www.browserstack.com/automate/selenium-4
https://www.browserstack.com/docs/automate/selenium/chrome-options
https://chromedriver.chromium.org/capabilities
One more source which may be the key statement of "truth" concerning Options is the new capabilities
https://www.selenium.dev/documentation/webdriver/getting_started/upgrade_to_selenium_4/
in particular
https://www.selenium.dev/documentation/webdriver/getting_started/upgrade_to_selenium_4/#capabilities
which then going back and cross referencing with BrowserStack's documentation they seems to be saying the same here
https://www.browserstack.com/automate/selenium-4
but I'll agree that the Python example code here with both the old "Legacy Protocol" and the new "W3C Protocol" putting it into a dictionary called desired_cap really does not help.
If I find some time tomorrow (I'm middle of night EDT/UTC-4) or really later today I will check in with David Burns - aka AutomatedTester - the Reviewer/Merger of the pull request you reference above over in the Selenium community Slack for clarification. Most likely we need to also depreciate the desired capability objects with the SeleniumLibrary and then make it clear through documentation how to go about with Selenium 4 way of handling this.
I asked over in the Selenium slack and Titus replied saying
Originally there was an idea of "desired capabilities" and "required capabilities," but most languages only implemented desired capabilities and everyone used them like they were required capabilities. Options by default are "required" capabilities.
The spec allows you to define capabilities in 2 different ways:
- First Match
- Always Match
First match is an array of capabilities properties and the server will use the first one it has matching node.
[my emphasis]
He added that he hadn't "checked to see which languages allow you to toggle between those". Looking further I see this matching strategy within the W3C spec. But searching through the Python Selenium API I don't see how it handles this part of the spec.
It would be my preference to simply depreciate and eventually remove desired_capabilities as a means to set the capabilities. Instead directing people to now and exclusively use Options. (There might be a slight problem with this as it looks like from the Python Selenium API desired_capabilites, at least as a method on the driver, is used to get what capabilities are being used. This is different but with similar name just helps to confuse things. Luckily we can hide this within a keyword which the SeleniumLibrary could name something like 'Get Current Capabilities' or the like - without using "desired").
WoW, that is comprehensive one!
Thanks for working on this.
I think you are right. desired_capabilites should be deprecated and use Options instead.
If it is the plan, shall we make a change on the Lib to make that happens?
Do we need more discussion on this deprecation?