Meeting minutes
<sadym> зкуыуте+
RRSAgent: make logs public
Should HTMLDocument nodes be serialized as web element reference
github: https://
whimboo: I started to work on serializing web elements and looking at the existing tests, I found one that gets the Document Node and Chrome will return an WebElement. This doesn't match the spec. I changed Firefox so it fails (as per spec, because the Document node is cyclic). Do we have data about whether this in use? Several commands in WebDriver don't work e.g. getAttribute. Would be clearer to say
we don't support this.
foolip: Is this classic or bidi?
whimboo: Classic?
foolip: Then I don't know. Classic has Element and Window handles?
whimboo: Element, Window, Frame and ShadowRoot
foolip: So it's a spec violation? [yes]
foolip: Is there a use case?
whimboo: We just discovered this when fixing another bug
foolip: File a chromedriver bug? Seems weird to support window and not document
simon: Window is used to switch to window
simon: document.documentElent would be the best thing to use. Classic doesn't do anything sophisticated here
WebDriver BiDi Meeting in Berlin
honza: Proposal for BiDi meeting in Berlin on Dec 1st at Google office. There should be a mail on the mailing list. Current capacity is 14. Want to maintain list of attendees. Proposed start time is 10am. Should have a possibility of joinging remotely using Google Meet.
honza: Any concerns about date?
simon: I can attend remotely. For people in US a later start might work better.
JimEvans: I'd also like to participate remotely.
Consider whether to allow multiple sessions in browsers #103.
github: https://
sadym: We had this question before and have it again in ChromeDriver implementation. We added a channel field which makes a unique id. It allows multiple sessions on a single webdriver connection. We can say that the server can implement multiple websocket connections, but it would just be one websocket connection on the server, and multiplexed by the channel.
jgraham: Not clear why you can't have a single server that accepts multiple connections. But if we want this why not use the sessionId directly?
sadym: All remote connections come to a single process. It can support multiple websocket connections. Does it have to tunnel all the connections to the same browser?
… we could have one session with multiple clients
ack
jgraham: It would be good to write up the case where this makes sense, because it's not clear at the moment where the existing mechnaisms don't work
Clarify extensibility rules
github: https://
sadym: When we call script.evaluate we can set a target that can be Context or Realm. What do we want to do in the case that a client sends a message that can match both. We have several options. One is to add an explicit type field to the message. Another option is to restrict extensions so that other fields aren't allowed and cause a protocol data. Or we specify a set of rules for which fields win.
jgraham: Fundamental questions are do we want extensibility at the level of inner protocol data, and if so are we OK with structural typing plus rules for disambigutaion, or nominal typing which is heavier weight.
simon: For typed lanaguages it helps if the types are unambigious
sadym: As mentioned on the issue, we have the same kind of ambiguity on the handles field. That makes it more ergonomic to just send back whatever you recieved without altering it. In this example, if we just say that "realm" is the winner it could be more ergonomic from that perspective; the user could just use the result they got from the server directly.
jgraham: I agree that for strongly typed languages (e.g. Rust, Java) this ambiguity is going to be a problem. For e.g. JS the opposite is probably true.
sadym: The client is controlling what to send here, so it doesn't run into this ambiguity.
simon: deserializers are written at a lower level, and don't often have the ability to map to one or more types. Relying on fields being present to determine the type feels risky. If you have both FooHandle and BarHandle that both want some 'id' field. Might be better to be explicit.
jgraham: I think that in this case the client will be sending the message, but we'll apply the precedent to browser-originating messages in the future
simon: ALso intermediate nodes might care
sadym: Another option for this case is to require always sending the realm, which you can always get.
jgraham: I don't think we should add extra roundtrips for this case
jgraham: I encourage enveryone to read the issue, since any changes here will be breaking
Do we need example scripts? Where should they be put?
sadym: We just created an example script that supports various implementations. Do we want that kind of example on the spec/wpt repo. It's intended to be easy to follow by someone who implements BiDi. We've seen users have problems implementing, this example could help with that.
sadym: I will create a GH issue
<sadym> https://
github: https://
jgraham: What's the mechansim to ensure that this will be kept up to date?
sadym: It could be run as a test in wpt
jgraham: wpt has a client already, but maybe that's not so useful for authors. Running example code in wpt is pretty unusual.
sadym: We could host it externally. We expect 9-10 scripts in total.
jgraham: I think we could host this on W3C GH or even in the spec repo, but it should have its own CI to verify the examples work as expected.
Update on `SharedReference`
github: https://
sadym: I expect to start working on this again in the next week or two.
`browser.close` command
github: https://
jgraham: Please review the PR. Two questions: should we provide a response to the command, and should we consider always sending a message before a clean browser shutdown?
sadym: It's not that hard to implement, but do we really need to send a response, given that we're going to drop the connection?
simon: It seems like good manners to nootify clients that you're about to shutdown, so that they can tell the difference between a network failure and clean shutdown.
whimboo: For marionette, we have a marionette:quit command. We return some properties about the kind of shutdown, which are useful for some test clients, so this might also be useful in BiDi. e.g. in Firefox a component can refuse to shutdown, and it can be useful for internal testing to know which one it was.
sadym: What about implementations where you have several WS connections. You might want to notify all the connections that the browser is about to shutdown. Can we postpone notifying all connections about being dropped, because that's harder to implement.
whimboo: For CDP does Browser.close have a response?
sadym: I'm not sure, but we can send a response and tehn drop the connection
jgraham: Sounds like there's consensus on sending a response, but we should postpone sending an event.
whimboo: Clients would also have to subscribe to the event.
jgraham: Clients have to handle the client unexpectedly shutting down as well as expected shutdown so can't rely on this.
load scripts
github: https://
jgraham: Mader a PR for load scripts (aka bootstrap scripts) following TPAC. Just addLoadScript/removeLoadScript, most of the implementation complexity is calling the scripts at the right time
sadym: When you have several load scripts for the same realm, which order do they run in?
jgraham: Yes I think so.
whimboo: so there's no way to add at the beginning without removing all existing scripts?
jgraham: That's correct. I don't think other protocols allow you to adjust the order. It's not clear how that would work in the face of multiple sessions all trying to add different load scripts (or even multiple components using the same session)
whimboo: Could we add a priority field? Then the client could specify the order within a given session.
jgraham: Would be good to know what use cases require that; maybe add them to the issue
sadym: If we guarantee that we run scripts before client scripts that should be enough.
RRSAgent: make minutes