16:02:12 RRSAgent has joined #webdriver 16:02:12 logging to https://www.w3.org/2022/10/12-webdriver-irc 16:02:17 Zakim has joined #webdriver 16:02:41 Meeting: WebDriver 16:03:16 Agenda: https://www.w3.org/wiki/WebDriver/2022-10-BiDi#Agenda 16:04:08 present+ 16:04:11 зкуыуте+ 16:04:17 present+ 16:04:19 present+ 16:04:39 RRSAgent: make logs public 16:04:47 Scribe: jgraham 16:04:57 present+ 16:05:04 Topic: Should HTMLDocument nodes be serialized as web element reference 16:05:24 present+ 16:05:40 github: https://github.com/w3c/webdriver/issues/1687 16:07:25 q+ 16:07:59 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 16:08:05 we don't support this. 16:08:07 ack foolip 16:08:20 foolip: Is this classic or bidi? 16:08:25 whimboo: Classic? 16:08:47 q+ 16:08:52 foolip: Then I don't know. Classic has Element and Window handles? 16:09:03 whimboo: Element, Window, Frame and ShadowRoot 16:09:18 foolip: So it's a spec violation? [yes] 16:09:39 foolip: Is there a use case? 16:09:50 whimboo: We just discovered this when fixing another bug 16:10:24 foolip: File a chromedriver bug? Seems weird to support window and not document 16:10:32 present+ 16:10:35 simon: Window is used to switch to window 16:10:42 q- 16:11:05 simon: document.documentElent would be the best thing to use. Classic doesn't do anything sophisticated here 16:11:35 Topic: WebDriver BiDi Meeting in Berlin 16:12:58 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. 16:13:33 honza: Any concerns about date? 16:13:55 simon: I can attend remotely. For people in US a later start might work better. 16:14:13 JimEvans: I'd also like to participate remotely. 16:14:50 Topic: Consider whether to allow multiple sessions in browsers #103. 16:15:01 github: https://github.com/w3c/webdriver-bidi/issues/103 16:16:43 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. 16:16:48 q+ 16:17:44 present+ 16:18:25 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? 16:19:16 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? 16:19:28 ... we could have one session with multiple clients 16:21:03 ack 16:21:08 ack jgraham 16:21:34 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 16:22:04 Topic: Clarify extensibility rules 16:22:20 github: https://github.com/w3c/webdriver-bidi/issues/274 16:24:06 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. 16:26:24 q+ 16:27:09 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. 16:27:22 simon: For typed lanaguages it helps if the types are unambigious 16:27:30 ack sadym 16:28:46 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. 16:28:51 q+ 16:30:53 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. 16:31:23 sadym: The client is controlling what to send here, so it doesn't run into this ambiguity. 16:32:30 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. 16:32:37 q+ 16:32:44 ack jgraham 16:33:53 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 16:34:01 simon: ALso intermediate nodes might care 16:34:31 sadym: Another option for this case is to require always sending the realm, which you can always get. 16:35:07 jgraham: I don't think we should add extra roundtrips for this case 16:35:23 q? 16:35:26 ack sadym 16:36:19 jgraham: I encourage enveryone to read the issue, since any changes here will be breaking 16:36:33 Topic: Do we need example scripts? Where should they be put? 16:37:59 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. 16:38:14 sadym: I will create a GH issue 16:38:31 https://github.com/w3c/webdriver-bidi/issues/309 16:38:48 github: https://github.com/w3c/webdriver-bidi/issues/309 16:39:43 jgraham: What's the mechansim to ensure that this will be kept up to date? 16:39:57 sadym: It could be run as a test in wpt 16:41:28 jgraham: wpt has a client already, but maybe that's not so useful for authors. Running example code in wpt is pretty unusual. 16:41:50 sadym: We could host it externally. We expect 9-10 scripts in total. 16:42:55 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. 16:43:26 Topic: Update on `SharedReference` 16:43:34 github: https://github.com/w3c/webdriver-bidi/pull/180 16:43:55 sadym: I expect to start working on this again in the next week or two. 16:44:50 Topic: `browser.close` command 16:44:59 github: https://github.com/w3c/webdriver-bidi/pull/286 16:46:40 q+ 16:46:55 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? 16:46:59 ack sadym 16:47:29 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? 16:47:37 q+ 16:48:09 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. 16:48:15 ack whimboo 16:48:16 q+ 16:49:37 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. 16:49:42 ack sadym 16:51:04 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. 16:51:18 whimboo: For CDP does Browser.close have a response? 16:51:35 sadym: I'm not sure, but we can send a response and tehn drop the connection 16:52:28 jgraham: Sounds like there's consensus on sending a response, but we should postpone sending an event. 16:52:36 whimboo: Clients would also have to subscribe to the event. 16:53:24 jgraham: Clients have to handle the client unexpectedly shutting down as well as expected shutdown so can't rely on this. 16:53:50 Topic: load scripts 16:54:01 github: https://github.com/w3c/webdriver-bidi/pull/292 16:56:13 q+ 16:56:54 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 16:56:58 ack sadym 16:57:32 sadym: When you have several load scripts for the same realm, which order do they run in? 16:57:55 q+ 16:58:18 jgraham: Yes I think so. 16:58:37 whimboo: so there's no way to add at the beginning without removing all existing scripts? 17:01:19 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) 17:01:28 ack whimboo 17:01:49 whimboo: Could we add a priority field? Then the client could specify the order within a given session. 17:02:05 q+ 17:02:26 jgraham: Would be good to know what use cases require that; maybe add them to the issue 17:02:51 sadym: If we guarantee that we run scripts before client scripts that should be enough. 17:03:39 RRSAgent: make minutes 17:03:39 I have made the request to generate https://www.w3.org/2022/10/12-webdriver-minutes.html jgraham 17:03:52 Zakim, bye 17:03:52 leaving. As of this point the attendees have been foolip, sadym, jgraham, whimboo, cb, PujaJagani, JimEvans 17:03:52 Zakim has left #webdriver 17:11:20 RRSAgent: bye 17:11:20 I see no action items