– DRAFT –
WebDriver October 2023 Monthly Meeting

Future of browsingContext.locateNodes

github: w3c/webdriver-bidi#547

<gsnedders> GitHub: w3c/webdriver-bidi#547

Jim Evans: We have reached the point in this PR that gives us the bare minimum to hava locators of elements to map over classic
… this was initially discussed at TPAC
… there are some questions around the PR. Do we want to land as is or do we want to start discussing command batching?

?

<gsnedders> github: w3c/webdriver-bidi#547

jgraham: My last comment on the PR is that I can see both sides on this. When looking at PR and in particular text locators is that its not what Selenium, playwright, or puppeteer do
… I am concerned that we will standardise prematurely here
… and the PR is closer to what Selenium does.
… and if we standardise prematurely that people might not use it and inject JS to get around it
… so I have a specific question that I have is "looking at the PR for the command batching does this look like a good use of the protocol?"
… I see 2 approaches. Have a generic batching command system or we have one for each command as it appears
… so I see that this conversation should happen in parallel to this conversation
… i feel like with actions we should have built a more generic appraoch

AutomatedTester: I don't want us to derail too much. To your point of this could be a fun engineering problem, I think there's a concern that we spend too much time prematurely optimising to get batching correct. I hope we can get something working and can build the more generic implementation later. With locators, I'm worried that if we carry on with the "inject js where we need it" we're relying too

much on the community to build the functionality. Selenium don't have the capacity to build something here.

shs96c: a couple of points; firstly it's a very important feature to have. We should get it landed and iterated over that. secondly, in classic we did talk about moving to innertext that we could hide behind capability
… thirdly <discusses innerText>

jgraham_ (IRC): how close is it to classic? It's pretty close but classic is a lot less flexible. and to David's comment it was 20 lines of code so it's not to be hard

shs96c: but you did mention that it can't do ShadowDOM and that needs to be handled. There might be other places that this could come up, we just know this 1 place

jrandolf: regarding batching. Looking at how batching generally works. Why cant we just have the generic and just let the server handle it like <something in kubenetes>

shs96c: Selenium wants the batching because they mostly use service providers. This means they use the client and a large amount of the internet.

jrandolf: my thought is that has made a client could inject the batching and then the server just reads it and breaks it down.
… so each driver could do this

shs96c: if each driver made their own there wouldn't be great interop. There are also providers who are trying to route this round and then having to figure things out could be extra complex
… and I agree with jgraham
… one command output could be the input for the next command

orkon: about the PR and landing it. We could land things here and we don't have objections of landing but we would need to do a final review and prototyping
… and batching we need it to be it's own discussion

jgraham: the use is to remove latency and there are user flows
… <gives an example where one locator flows into another especially around Shadow piercing>
… it's kinda like a Promise graph that needs to be sent across the wire. But if people see there is a lot of value in getting it landed let's do that

Jim Evans: as I mentioned in the issue around batching is that if we do it then I think it will open a wealth of new features but I have a lot of ideas and use cases that I can collaborate with. I think this could be a really massive game changing feature

shs96c: Do we have someone that is able to do this feature or is it going to be a nice to have and won't be worked on in 3-6 months

Make context/navigable id per session

github: w3c/webdriver-bidi#565

<jgraham_> (I will note that the question later in the agenda of "Should we make setFiles part of performActions instead?" is exactly why I don't like that we have these one-off commands that enable sequencing multiple things)

<jrandolf> jgraham_: +1

whimboo: describes the issue about if ids are shared between the sessions, there are pros and cons for this approach and we can start a discussion if ids should be the same

jgraham_ (IRC): I wrote the PR to make context ids isolated so that different sessions don't know about each and if you want to share the data between two clients you can use the same session

<orkon> we lost meeting?

<jrandolf> Uh

<whimboo> please just rejoin

<AutomatedTester> sorry...

<AutomatedTester> I have restarted it

<shs96c> :)

orkon: There could be cases where it's interesting to not have isolation for context id e.g. debugging so you can tell if objects are the same or not. it might be nice to have it as an option, but I don't know if it's possible.

whimboo: if we can use the same session if the client needs the same id. If we do not need it, then a new session can be created

jgraham_ (IRC): is it easier to debug if the browser state is a global shared state, not known about other sessions and perhaps we should have revises the decision about the node ids?

jgraham_ (IRC): on the other hand, I worry if there will be a security risk here. But perhaps a session should not be a security boundary.

orkon: Isolating node ids seems OK, but I'm not sure what the difference is between contexts and elements. Maybe it's because events are bound to context ids. I think there would still be ways to identify the same tab / frame. No strong opinion.

Standardize errors thrown when a command needs to be aborted (GitHub issue)

jgraham_ (IRC): lets discuss on the PR, it sounds like PR could be landed.

<jgraham_> github: w3c/webdriver-bidi#540

whimboo: there are problems with Puppeteer: how should we handle commands that are interrupted? For example, script evaluation can be interruped by a navigation. For those cases we don't have anything in the spec and it would be great to have a specific error

whimboo: so that the client can decide on the abort error what to do with the command

whimboo: right not it is not possible for the client to have a correct behaviour

jgraham_ (IRC): I agree we need this. From the spec point of view it is a bit tricky. I guess what we need a generic handler in the spec that if unload handler is invoked, then each running command is abort. Except maybe navigation commands because it should not be aborted. To begin with we could put a vague wording.

<gsnedders> ack

jgraham_ (IRC): we should have a DocumentNavigated error to know that the command was aborted

Sam Sneddon [:gsnedders]: we cannot use the unload handler because the unload handler can be cancelled in some circumtances.

jgraham_ (IRC): I was thinking in the spec terms to be after there is no possibility to cancel the unload

jgraham_ (IRC): in gecko we get a notification that a context is being destroyed

Sam Sneddon [:gsnedders]: I think the complexity will be on how to spec this

input.setFiles

<jgraham_> github: w3c/webdriver-bidi#494

orkon: In classic this is doen via sendkeys, which is part of actions

jgraham_ (IRC): I think it does not need to be part of actions. Like Henrik said element send keys is a separate command.

jgraham_ (IRC): the implementation can distinguish between the cases and invoke setFiles because in the clients it is not possible to send keys as part of the input sequence

jgraham_ (IRC): I suspect if you send key events in classic while focused on an input element, probably nothing would happen

jgraham_ (IRC): will take a look at PRs

<jgraham_> RRSAgent: make minutes