desired_capabilities is not respected for remote browser

[RyanSiu1995]

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.

[emanlove]

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.

[RyanSiu1995]

Either way works for me.
But I can't specify capabilities in the Open Browser keyword unfortunately.
The only supported option is desired_capabilities

[emanlove]

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

[emanlove]

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.

[emanlove]

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.

[emanlove]

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").

[RyanSiu1995]

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?

[emanlove]

This issue has been resolved by usage of the options class. Closing this issue as such.