Skip to content
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

Clean up capabilities of non-W3C capability names #253

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

emilorol
Copy link

@emilorol emilorol commented Nov 1, 2019

This change will allow the manual start for all major browsers including IE 11 and Edge 18.

Ideally you will keep the alwaysMatch, but then Edge will shock on it.

Note: I also update the CURL sample code to display the change

selenoid-ui-manual-sessions

"selenoid:options": {
enableVNC: true,
sessionTimeout: "60m",
labels: { manual: "true" },
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this is breaking change actually

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was following another documentation and also the Selenium-Webdriver implementation.

An even the mozilla mention the list of as:

  • acceptInsecureCerts
  • browserName
  • browserVersion
  • platformName
  • pageLoadStrategy
  • proxy
  • setWindowRect
  • timeouts
  • unhandledPromptBehavior

Therefore limiting the capabilities just to the allowed properties should not brake anything. I test it locally with out issues. Also while adding firstMatch or alwaysMatch is accepted it does create an issue for Microsoft Edge. The selenoid:options are still passed, but in the desiredCapabilities without having the use the reserve name selenoid:options.

@lanwen
Copy link
Collaborator

lanwen commented Nov 16, 2019

https://developer.mozilla.org/en-US/docs/Web/WebDriver/Capabilities

can you point to the document which stands that removed caps are not compliant?

More than that it explicitly saying

The first thing you need to know is that alwaysMatch/firstMatch is always wrapped inside a capabilities JSON Object, whereas desiredCapabilities/requiredCapabilities exists at the top level

@emilorol
Copy link
Author

I was following another documentation and also the Selenium-Webdriver implementation.

An even the mozilla mention the list of as:

  • acceptInsecureCerts
  • browserName
  • browserVersion
  • platformName
  • pageLoadStrategy
  • proxy
  • setWindowRect
  • timeouts
  • unhandledPromptBehavior

Therefore limiting the capabilities just to the allowed properties should not brake anything. I test it locally with out issues. Also while adding firstMatch or alwaysMatch is accepted it does create an issue for Microsoft Edge. The selenoid:options are still passed, but in the desiredCapabilities without having the use the reserve name selenoid:options.

@lanwen
Copy link
Collaborator

lanwen commented Nov 17, 2019

I think you misread something in the spec. Spec says exactly the same - and firstMatch or alwaysMatch are required inside of the capabilities node. (Even in the implementation code)

https://www.w3.org/TR/webdriver/#dfn-capabilities-processing

Also, there are extensions to the standard caps which are defined in the form of <vendor>:<namespace>.

Most probably you're facing the the Edge/IE issue not implementing this spec properly and responding to the desiredCapabilities only, failing to parse capabilities according to the spec.

So there are 2 ways of fixing this: having a dedicated request for edge/ie, or delegate that job to selenoid.
Summon @vania-pooh here to ask if the selenoid should ever think about vendor-specific hacks. Also, the spec says that intermediate node (selenoid in our case) should exclude their custom caps (selenoid:options in our case) and do not forward them to the node (written in the create session section). Maybe that could be an issue as well.

@lanwen
Copy link
Collaborator

lanwen commented Nov 17, 2019

So following w3c logic only

                "enableVNC": true,
                "name": "this.test.is.launched.by.curl",
                "sessionTimeout": "120s"

are non-w3c-compliant and should not be in the always/first match nodes on the top level (and they are not there)

@emilorol
Copy link
Author

I was trying to avoid a conditional logic just to satisfy Edge issues with firstMatch or alwaysMatch and the current proposed solution works with all. Since you are still passing the Solenoid options in the desiredCapabilities, you are really not missing them.

@vania-pooh
Copy link
Member

No, we are not going to maintain vendor-specific hacks. There is nothing in the spec saying that vendor-specific capabilities for intermediary node (i.e. Selenoid) should not be present in the request to endpoint node (i.e. webdriver binary).

@lanwen
Copy link
Collaborator

lanwen commented Nov 18, 2019

Hmm
image

@lanwen
Copy link
Collaborator

lanwen commented Nov 18, 2019

okay, so I would try to fix that in selenoid first and then let's see what happens

@lanwen lanwen added the on-hold label Nov 18, 2019
@lanwen
Copy link
Collaborator

lanwen commented Jan 17, 2020

fix for aerokube/selenoid#771 was released, it could help, can you verify that?

@emilorol
Copy link
Author

I was not aware of that issue. How can I help?

@lanwen
Copy link
Collaborator

lanwen commented Jan 17, 2020

basically all we discussed here was fixed in the latest selenoid release

@emilorol
Copy link
Author

I was able to test, and I can not start IE or Edge manual sessions.

Here are the errors I am getting:

2020/01/22 15:12:58 [-] [NEW_REQUEST] [unknown] [192.168.10.154]
2020/01/22 15:12:58 [-] [NEW_REQUEST_ACCEPTED] [unknown] [192.168.10.154]
2020/01/22 15:12:58 [12] [LOCATING_SERVICE] [MicrosoftEdge] [18.0]
2020/01/22 15:12:58 [12] [USING_DOCKER] [MicrosoftEdge] [18.0]
2020/01/22 15:12:58 [12] [CREATING_CONTAINER] [nexus.internal.com:8443/docker/windows:browsers]
2020/01/22 15:12:58 [12] [STARTING_CONTAINER] [nexus.internal.com:8443/docker/windows:browsers] [97e96226b25fc43dccc43c9351de672e7c815e301beb8e65daa02525677a865b]
2020/01/22 15:12:58 [12] [CONTAINER_STARTED] [nexus.internal.com:8443/docker/windows:browsers] [97e96226b25fc43dccc43c9351de672e7c815e301beb8e65daa02525677a865b] [0.13s]
2020/01/22 15:13:06 [12] [SERVICE_STARTED] [nexus.internal.com:8443/docker/windows:browsers] [97e96226b25fc43dccc43c9351de672e7c815e301beb8e65daa02525677a865b] [7.40s]
2020/01/22 15:13:06 [12] [PROXY_TO] [97e96226b25fc43dccc43c9351de672e7c815e301beb8e65daa02525677a865b] [http://172.17.0.4:5555/]
2020/01/22 15:13:06 [12] [SESSION_ATTEMPTED] [http://172.17.0.4:5555/] [1]
2020/01/22 15:13:06 [12] [SESSION_FAILED] [http://172.17.0.4:5555/] [400 Bad Request]
2020/01/22 15:13:06 [12] [REMOVING_CONTAINER] [97e96226b25fc43dccc43c9351de672e7c815e301beb8e65daa02525677a865b]
2020/01/22 15:13:06 [12] [CONTAINER_REMOVED] [97e96226b25fc43dccc43c9351de672e7c815e301beb8e65daa02525677a865b]


2020/01/22 15:13:49 [-] [NEW_REQUEST] [unknown] [192.168.10.154]
2020/01/22 15:13:49 [-] [NEW_REQUEST_ACCEPTED] [unknown] [192.168.10.154]
2020/01/22 15:13:49 [23] [LOCATING_SERVICE] [internet explorer] [11.0]
2020/01/22 15:13:49 [23] [USING_DOCKER] [internet explorer] [11.0]
2020/01/22 15:13:49 [23] [CREATING_CONTAINER] [nexus.internal.com:8443/docker/windows:browsers]
2020/01/22 15:13:49 [23] [STARTING_CONTAINER] [nexus.internal.com:8443/docker/windows:browsers] [9001b195075f12581b063f2d59ed271587cb62db1670384594ccc9bd7756686d]
2020/01/22 15:13:49 [23] [CONTAINER_STARTED] [nexus.internal.com:8443/docker/windows:browsers] [9001b195075f12581b063f2d59ed271587cb62db1670384594ccc9bd7756686d] [0.13s]
2020/01/22 15:13:56 [23] [SERVICE_STARTED] [nexus.internal.com:8443/docker/windows:browsers] [9001b195075f12581b063f2d59ed271587cb62db1670384594ccc9bd7756686d] [7.53s]
2020/01/22 15:13:56 [23] [PROXY_TO] [9001b195075f12581b063f2d59ed271587cb62db1670384594ccc9bd7756686d] [http://172.17.0.4:4444/]
2020/01/22 15:13:56 [23] [SESSION_ATTEMPTED] [http://172.17.0.4:4444/] [1]
2020/01/22 15:13:56 [23] [SESSION_FAILED] [http://172.17.0.4:4444/] [500 Internal Server Error]

This is my browsers file:

    "internet explorer": {
        "default": "11.0",
        "versions": {
            "11.0": {
                "image": "nexus.internal.com:8443/docker/windows:browsers",
                "port": "4444",
                "path": "/",
                "privileged": true,
                "env": ["SCREEN_RESOLUTION=3200x2450x24"]
            }
        }
    },
    "MicrosoftEdge": {
        "default": "18.0",
        "versions": {
            "18.0": {
                "image": "nexus.internal.com:8443/docker/windows:browsers",
                "port": "5555",
                "path": "/",
                "privileged": true,
                "env": ["SCREEN_RESOLUTION=3200x2450x24"]
            }
        }
    },

One more thing. I can start a manual session using CURL with the following body:

{ 
  "desiredCapabilities":{
    "browserName":"MicrosoftEdge", 
    "version": "18.0", 
    "enableVNC": true,
    "name": "Manual session",
    "labels": { "manual": "true"},
    "sessionTimeout": "60m"
  },
  "capabilities": {
    "browserName": "MicrosoftEdge", 
    "browserVersion": "18.0"
  }
}

@lanwen
Copy link
Collaborator

lanwen commented Jan 22, 2020

@emilorol thx for the extensive answer, we will try to investigate more on the selenoid side

@github-actions github-actions bot added the stale label Jan 15, 2024
Copy link

codecov bot commented Jan 15, 2024

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 35.15%. Comparing base (120cd42) to head (63df8af).
Report is 177 commits behind head on master.

Additional details and impacted files
@@           Coverage Diff           @@
##           master     #253   +/-   ##
=======================================
  Coverage   35.15%   35.15%           
=======================================
  Files          36       36           
  Lines         640      640           
  Branches       98       98           
=======================================
  Hits          225      225           
  Misses        362      362           
  Partials       53       53           
Flag Coverage Δ
go 35.15% <ø> (ø)
ui 25.00% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@github-actions github-actions bot removed the stale label Jan 19, 2024
@github-actions github-actions bot added stale and removed stale labels Mar 20, 2024
@github-actions github-actions bot added the stale label May 21, 2024
@github-actions github-actions bot removed the stale label Jul 26, 2024
@github-actions github-actions bot added stale and removed stale labels Sep 24, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants