-
Notifications
You must be signed in to change notification settings - Fork 197
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
Refactor session handling for better integration with BiDi #1608
Conversation
|
||
<li><p>Let <var>body</var> be a JSON <a>Object</a> initialised with: | ||
|
||
<dl> | ||
<dt>"<code>sessionId</code>" | ||
<dd><var>session id</var> | ||
<dd><var>session</var>'s <a>session ID</a>. | ||
|
||
<dt>"<code>capabilities</code>" | ||
<dd><var>capabilities</var> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe this should be similar to session id?
<dd><var>capabilities</var> | |
<dd><var>session</var>'s <a>capabilities</a> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's the same <var>capabilities</var>
as defined above, so I don't think this change is required.
index.html
Outdated
<li><p><a>Set the current top-level browsing context</a> | ||
for <var>session</var> with the <a>top-level browsing context</a> | ||
<li><p>Set the <a>current top-level browsing context</a> | ||
of <var>session</var> to the <a>top-level browsing context</a> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
should we add: of the currently selected tab
? Otherwise it would be unclear in case the browser starts up with multiple tabs already open.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This part generally doesn't make sense, we can't set the current top level browsing context to the current browsing context, because that doesn't exist. Basically I think the UA is free to pick any borwsing context at this point, but I've tried to add some language suggesting it should pick a reasonable one.
dcc017b
to
8717fbe
Compare
CC'ing @foolip and @bwalderman for their reviews. It would be great to get this PR landed. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we'll need to be particularly careful to make sure that it's possible to reformulate this spec on top of Bidi, and I've called out a few places where I'm not sure that would be possible with this PR.
index.html
Outdated
to their corresponding values. | ||
<li><p>If <var>request match</var> is of type <a>error</a>, | ||
<a>send an error</a> with <var>request match</var>’s <a>error code</a> | ||
and continue. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess the intent here is that the returned error is forwarded to the local end? We should also ensure that error
's data
is also returned.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
An error doesn't have data, only a code. But the send an error
steps allow the implementation to provide an arbitary message so the intent is really that we give the user some useful information, without wanting to specify exactly what that must be.
[some time later after reading the spec again]
Ah, I see there's an error data
concept that is apparently exclusively used with unexpected alert open
. Unfortunately it looks like that isn't hooked up to the error handling infrastructure at all corrrectly. I don't really want to further scope-creep this PR by also fixing that, but it could be fixed. Mind filing an issue?
index.html
Outdated
<ol> | ||
<li><p>Let <var>session id</var> be the corresponding variable | ||
from <var>command parameters</var>. | ||
<li><p>If <var>URL variables</var> has an item named session id: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It would be helpful to indicate that "session id" is a variable name.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's not really a variable name though; it's the name of the field in a struct. In other specs it seems like the fields of the struct are individually defined, so that they can be linked on use. But since the fields of the struct in this case depend on which template variables were populated it seems harder to use that pattern. So I'm not realy sure what the cleanest way to mark this up is.
index.html
Outdated
<a>send an error</a> with <a>error code</a> <a>invalid session id</a>, | ||
then jump to step 1 in this overall algorithm. | ||
<ol> | ||
<li><p>Let <var>session id</var> be <var>URL variables</var>'s session id. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Here too
index.html
Outdated
amongst <a>all associated cookies</a> | ||
of the <a>current browsing context</a>’s <a>active document</a>, | ||
return <a>success</a> with the <a>serialized cookie</a> as data. | ||
<li><p>If the <var>URL variables</var>' name is equal to |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Missing s
after the apostrophe
I've done a round of fixup here. One thing that apparently isn't very obvious from the text is how I'm thinking about the session flags. The basic idea was to have a single kind of session object, but let it compose together the HTTP session and BiDi session properties, so that we can have all of the combinations HTTP-only, BiDi-only, HTTP+BiDi, and extend to anything new we want in the future. So the idea was that the flags are used to specify which kind of session a given session is, and knowing that you can tell what properties it must have e.g. if a session is a HTTP session it must have a timeouts property that you can access, but a BiDi session doesn't. The idea wasn't to group together all the boolean properties of a session into a single flags object. |
it looks like there are no remaining unanswered questions and this PR needs a rebase? |
7e9826c
to
37d2eb9
Compare
With BiDi we want to support multiple sessions, at most one of which can also enable the HTTP frontend. Therefore we add the concept of multiple sessions, which can have different flags set according to the protocols they support (http, bidi, etc.). This explictly passes the session, parameters and url variables down into each command. In addition the URL variables are handled as a infra struct rather than as a custom thing with implied variables. Instead of having a concept of the "current session" we explicitly pass the session around where required.
37d2eb9
to
7ca2626
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM (@sadym-chromium PTAL)
Co-authored-by: Maksim Sadym <69349599+sadym-chromium@users.noreply.github.com>
Review is outdated now; going to land this to prevent further bitrot, but if there are remaining issues we can handle those in followups.
SHA: 63a397f Reason: push, by jgraham Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
SHA: 63a397f Reason: push, by pull[bot] Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
SHA: 63a397f Reason: push, by pull[bot] Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
This is a large change, but it's almost entirely refactoring.
The main aim here is to split the session concept so that there's a base "session" which holds the session id and state that's appropriate to both WebDriver classic and BiDi. Then, we define a "HTTP Session" as one that has the HTTP Flag set and use that to compose-in any state that's only used in the classic HTTP-based protocol.
In addition, we rework the way state is passed around the spec so that we are using an explicit session object, rather than making use of a global "current session". This makes things clearer if we allow the possibility of multiple non-HTTP sessions.
There is also a bit of cleanup in the way we pass other variables around, and in the capabilites processing.
Preview | Diff
Preview | Diff