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

Add the ability to start a session directly with the bidi connection #99

Merged
merged 10 commits into from
Sep 22, 2021

Conversation

jgraham
Copy link
Member

@jgraham jgraham commented Apr 13, 2021

The case for this is:

  • Some clients might be uninterested in using the classic WebDriver
    HTTP connection, and want to avoid depending on a HTTP client just for
    session creation.

  • Some implementations might ship the HTTP server as a seperate
    component, but have the bidi connection built-in to the browser
    itself. This will allow clients to use bidi without a seperate driver
    binary (similar to devtools) without requiring the browser to ship a
    full HTTP implementation just for new session.

  • It is needed to "explain" the behaviour of classic WebDriver in
    terms of the BiDI protocol; in particular the new session and session
    status command.

Implementation-wise the model is that a remote end is allowed to start
a WebSockets server that accepts connections to the /session
resource. This connection can then be used for "static" commands
i.e. those which don't require a session. Currently this is just
session.status and session.new. Once session.new is called, the
same WS connection is reused for subsequent commands that are part of
the session.


Preview | Diff

@jgraham
Copy link
Member Author

jgraham commented Apr 13, 2021

I didn't fill in the details of session creation and plan to wait for consensus on the general approach first. Doing ti correctly probably requires refactoring the WebDriver spec to make the capabilites processing and session creation an algorithm that can be invoked from the BiDI spec.

@css-meeting-bot
Copy link
Member

The Browser Testing and Tools Working Group just discussed Bidi only sessions.

The full IRC log of that discussion <AutomatedTester> topic: Bidi only sessions
<AutomatedTester> github: https://github.com//pull/99
<AutomatedTester> jgraham: we have been standing up the initial implementation in Gecko
<AutomatedTester> ... one of the questions that came up was "should we allow people to start a session without going via HTTP session"
<AutomatedTester> ... its for clients that never care about the http commands that webdriver has
<AutomatedTester> ... and then there are existing tools like puppeteer/playwright
<brwalder> q+
<AutomatedTester> ... from Mozilla we don't really want to ship a http server in Firefox
<AutomatedTester> ... or we can rewrite the webdriver http spec to show how this maps across to webdriver bidi
<AutomatedTester> ... and I have created a PR on how this could work
<AutomatedTester> ... [ describes what is in the PR ]
<AutomatedTester> q?
<AutomatedTester> ack brwalder
<simonstewart> q+
<drousso> q+
<jgraham> q+
<AutomatedTester> brwalder: in chromium we ahve a link between webdriver and browser processes that is 1:1. This is done when things are started up and we go from there. I am not against connecting to an existing browser just mentioning it
<AutomatedTester> q?
<AutomatedTester> ack simonstewart
<brwalder> q+
<AutomatedTester> simonstewart: I don't mind, from selenium, that we connect to a websocket but we need a sessionID so we can make sure that intermediary nodes route things to the right place
<AutomatedTester> q?
<AutomatedTester> ack drousso
<AutomatedTester> drousso: I don't know if we want to expose the websocket because of security/privacy concerns
<AutomatedTester> q?
<AutomatedTester> ack jgraham
<AutomatedTester> jgraham: I don't think we want people to have start up the standard browser and there is websocket open as that is a security nightmare
<AutomatedTester> ... e.g you would need to tell the browser to start up with a websocket via a driver
<AutomatedTester> ... my question is mostly around do we need to do a start a session by calling HTTP POST /SESSION first or connect to a websocket first
<AutomatedTester> ... and to brwalder comment I think I have already handled the use case you've mentioned
<AutomatedTester> ... [describes a use case for 2 tools running]
<AutomatedTester> ... which won't work in the original webdriver because of the blocking commands there
<brwalder> q-

@jgraham jgraham force-pushed the new_session_bidi branch 4 times, most recently from 9f93856 to f474a1d Compare June 16, 2021 19:19
@jgraham jgraham marked this pull request as ready for review June 16, 2021 19:26
@jgraham
Copy link
Member Author

jgraham commented Jun 16, 2021

There is a big open issue about how to deal with capabilities that are maybe not relevant for non-HTTP sessions, but I think this is ready for some wider review.

@jgraham
Copy link
Member Author

jgraham commented Jul 14, 2021

I've reworked this to depend on the changes in w3c/webdriver#1608

This allows the possibility of both BiDi sessions and multiple sessions (though doesn't require support for either).

index.bs Outdated Show resolved Hide resolved
index.bs Outdated Show resolved Hide resolved
index.bs Show resolved Hide resolved
index.bs Outdated Show resolved Hide resolved
index.bs Show resolved Hide resolved
index.bs Outdated Show resolved Hide resolved
index.bs Show resolved Hide resolved
index.bs Outdated Show resolved Hide resolved
@whimboo
Copy link
Contributor

whimboo commented Sep 13, 2021

Fixes issue #97

index.bs Outdated Show resolved Hide resolved
index.bs Outdated Show resolved Hide resolved
index.bs Outdated Show resolved Hide resolved
index.bs Outdated Show resolved Hide resolved
index.bs Show resolved Hide resolved
index.bs Outdated Show resolved Hide resolved
index.bs Outdated Show resolved Hide resolved
index.bs Show resolved Hide resolved
The case for this is:

* Some clients might be uninterested in using the classic WebDriver
HTTP connection, and want to avoid depending on a HTTP client just for
session creation.

* Some implementations might ship the HTTP server as a seperate
component, but have the bidi connection built-in to the browser
itself. This will allow clients to use bidi without a seperate driver
binary (similar to devtools) without requiring the browser to ship a
full HTTP implementation just for new session.

* It is needed to "explain" the behaviour of classic WebDriver in
terms of the BiDI protocol; in particular the new session and session
status command.

Implementation-wise the model is that a remote end is allowed to start
a WebSockets server that accepts connections to the `/session`
resource. This connection can then be used for "static" commands
i.e. those which don't require a session. Currently this is just
`session.status` and `session.new`. Once `session.new` is called, the
same WS connection is reused for subsequent commands that are part of
the session.
@foolip foolip merged commit 618a27e into master Sep 22, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants