00:31:30 RRSAgent has joined #webdriver 00:31:30 logging to https://www.w3.org/2019/09/20-webdriver-irc 00:31:36 Zakim has joined #webdriver 00:31:57 RRSAgent, this meeting spans midnight 00:32:15 Hexcles has joined #webdriver 00:32:31 Chair: AutomatedTester 00:32:38 present+ 00:32:41 titusfortner has joined #webdriver 00:33:07 agenda: https://docs.google.com/document/d/1gUm7Be-akW2-4mjr15cnZlzwoAfOlfL7b3tWCDrb1Jg/edit# 00:33:10 present+ 00:33:13 present+ 00:33:17 present+ 00:33:51 JohnChen has joined #webdriver 00:33:54 Meeting: Browser Tools- and Testing WG, Day 2, TPAC 2019, Fukuoka 00:34:09 rrsagent, this meeting spans midnight 00:34:31 RRSAgent, make logs public 00:34:34 present+ 00:34:40 RRSAgent, create minutes v2 00:34:41 I have made the request to generate https://www.w3.org/2019/09/20-webdriver-minutes.html jgraham 00:34:48 mmerrell has joined #webdriver 00:34:49 present+ 00:35:15 present+ 00:35:16 drousso has joined #webdriver 00:36:36 present+ 00:36:45 Chair: AutomatedTester 00:36:52 CalebRouleau has joined #webdriver 00:37:32 bwald_ has joined #webdriver 00:39:26 present+ 00:40:41 present+ 00:41:51 topic: bi-directional communication 00:41:52 present+ 00:42:02 https://docs.google.com/spreadsheets/d/1mZGuKR4SR6HGhqf4wTJQg6eJQBkqnP4G3ibkPTIP_1Q/edit#gid=2126300658 00:42:09 present+ 00:42:12 everyone should mark themself present 00:42:31 present+ 00:42:33 present+ 00:42:37 scheib has joined #webdriver 00:42:37 I hast marked mineself as being present 00:42:38 zghadyali has joined #webdriver 00:42:38 present+ 00:42:39 present+ 00:42:40 present+ 00:42:45 present+ 00:42:53 AutomatedTester: continuation of the bi-di talk. centered around proper examples 00:43:14 ... need to start from implementation and go backward 00:43:14 bwald_ has joined #webdriver 00:43:21 q+ 00:43:21 present+ 00:43:27 AutomatedTester: start with "loading", how we'd do navigation 00:43:43 CalebRouleau: first thing would be to target a navigation (across tabs) 00:44:02 q+ 00:44:12 ack JohnChen 00:44:33 JohnChen: we start with how nav is initiated. the DevTools method is that every tab is a separate tab, and choosing which tab needs to navigate is significant 00:44:56 .. page.navigate() has 2 params, the tab (the target) and the URL 00:45:16 https://chromedevtools.github.io/devtools-protocol/tot/Page#method-navigate 00:45:16 kdzwinel has joined #webdriver 00:46:41 ... 3 other events: page.frameStartedLoading(), happens when the HTML is received. before that, nav is tentative (not committed yet), but once loading actually begins, a page.load event is fired 00:46:54 ... page.frameStopLoading event indicates the loading is done 00:47:12 q? 00:47:17 scribenick: mmerrell 00:47:20 ... chrome monitors for these events, and makes decisions based on that. This is how loading happens with CDP 00:47:27 brrian: why are we talking about this? 00:47:37 AutomatedTester: we're trying to use an example of a command, and working backward 00:47:37 s/frameStopLoading/frameStoppedLoading/ 00:47:46 ack brrian 00:47:51 brrian: is this part of the use case we talked about yesterday? 00:47:52 q+ 00:47:55 JohnChen: yes 00:48:07 brrian: this seems like a duplicate 00:48:23 jgraham: if the use cases don't include this the use cases are wrong 00:48:39 RRSAgent: make minutes 00:48:39 I have made the request to generate https://www.w3.org/2019/09/20-webdriver-minutes.html AutomatedTester 00:48:56 q- 00:49:09 jgraham: the point isn't to discuss every command, the point is to cover things that are fundamental to the protocol, of which navigation is one 00:49:40 boaz has joined #webdriver 00:49:58 q+ 00:50:03 jgraham: there should be some way in the bi-di protocol to initiate navigation, the requests, responses, etc. We need to discuss this, because it's the base part of the framework for the whole conversation 00:50:25 q? 00:50:29 q+ 00:50:47 brrian: this isn't part of the use cases 00:51:18 CalebRouleau: we should be discussing navigation because it's more contentious, while we're here in the room, rather than discussing something like logging, where we'll probably agree on everything 00:52:00 lukebjerring: it's easier to start with a use case that involves every part of the protocol 00:52:29 jgraham: nav is a necessary component of a rewrite of the protocol 00:52:41 simonstewart: it's not necessary, but it's already in there 00:52:53 s/but it's/and it's/ 00:52:54 jgraham: but we've already demonstrated that the discussion has been incomplete 00:53:40 simonstewart: if the purpose here is a re-do of the bi-di protocol, then it makes sense to do load. if it's to discover the shape of how to do it, that discussion is worth having 00:54:07 q? 00:54:13 ack simonstewart 00:54:17 q+ 00:54:20 ack JohnChen 00:54:23 JohnChen: one use case was the request modification (intercept), which has been covered in the CDP 00:54:24 q+ 00:55:30 JohnChen: we could insert an event in front of the loading call, which would allow this kind of interception in a way that is non-blocking, which fosters an async loading of the page in parallel with the intercept 00:55:33 ack drousso 00:56:00 q+ 00:56:08 q+ 00:56:11 drousso: the idea of loading a page, and intercepting a request, are two separate things entirely. It's not necessary to talk about these things at the same time... the only thing that overlaps is that they're going across the netork 00:57:11 q+ 00:57:18 ... a lot of what's being proposed comes down to data, and we need to discuss the shape of what it is and how it goes, not about the combinations of these concerns in a specific implementation 00:57:44 JohnChen: whatever script is running on the page disappears once the load event changes 00:57:54 q- 00:58:14 drousso: you should be able to send a script to the driver, which executes just prior to a load event 00:58:43 CalebRouleau: but JavaScript can't do everything we want, so we need to talk about it as a separate issue 00:59:49 jgraham: this comes down to script execution, though, not bi-di fundamentals. We need to understand the nature of the bi-di communication in order to agree on how to proceed in this conversation 01:00:12 CalebRouleau: this is getting too meta, so I suggest getting back to concrete examples 01:00:13 q? 01:00:43 q- 01:01:10 q+ 01:01:43 CalebRouleau: we should talk about logging, which will give us the context that fosters agreement on a framework or bi-di 01:02:04 q? 01:02:27 q+ 01:02:31 q+ 01:02:38 jgraham: talking about logging risks too deep a dive into a simple use case, where we'll get distracted from discussing the nature of bi-di communication 01:03:03 q- 01:03:12 q+ 01:03:19 AutomatedTester: with logging, we *won't* discuss the particulars of logging, we'll stick to the fundamentals of the packets and how they look 01:03:42 bwald_: that will include transports, correct? 01:03:56 q? 01:03:57 jgraham: yes, but there's a risk that we're leaving too much out 01:04:05 [general agreement on moving forward] 01:04:18 simonstewart: we should also include the handshake 01:04:30 I will paste this again to make sure everyone has read Google's description: https://docs.google.com/document/d/1eJx437A9vKyngOQ49lYYD3GspDUwZ6KpKDgcE2eR00g/edit# 01:04:40 Hexcles_ has joined #webdriver 01:04:45 jgraham: has the position changed since TPAC 2018? the conclusion was around a capability that included "bi-di". Has that changed? 01:05:31 q?q? 01:05:38 JohnChen: our prototype allows for that capability, which "upgrades" the connection to one that goes via a websocket, but which doesn't exactly hand back a websocket connection. It keeps the websocket connetion between the client and the browser, not exposing it further 01:06:22 simonstewart: the top-level return payload should include the "upgrade URL", but which can be re-written 01:07:18 q? 01:08:27 RESOLVED: Bi-di is always enabled. An optional capability, defaulting to true, indicating that bi-di is desired. When a new session is established, the return value of the new session contains the new top-level property of the bi-directional URL 01:08:40 I have made the request to generate https://www.w3.org/2019/09/20-webdriver-minutes.html ato 01:09:45 scribenick: automatedtester 01:09:51 q? 01:09:59 q- 01:10:10 q- 01:10:25 CalebRouleau: are we going to be doing 1 URL or multiple 01:10:29 simonstewart: 1 01:11:10 ack brrian 01:11:15 https://www.jsonrpc.org/specification 01:11:20 q- 01:11:33 scribenick: mmerrell 01:12:34 brrian: I propose that we send commands in events. We can work through examples, but it needs to go via JSON, which can include binary data 01:12:59 q? 01:13:01 brrian: there are . alot of tools available for generating code that can use this, incl C, JS, C#, etc. We should discuss 01:13:13 jgraham: is this close to existing implementations? 01:13:24 bwald_: we should start with JSON RPC. I second 01:13:24 ack bwald_ 01:13:45 ... CDP is basically already JSON RPC, only missing a couple things 01:13:54 q- 01:14:28 brrian: one difference is that JSON RPC is very particular about one request, one response. You have to batch things together. We should write tests for this, but ultimately adhere to the JSON RPC protocol 01:15:07 bwald_: it's proposed that the bi-directional WebDriver protocol uses JSON RPC 01:15:28 jgraham: we would need to study the standard more before agreeing to this 01:15:39 q+ 01:16:11 JohnChen: there are some pieces to this that would be a challenge for us to conform to, particularly around notifications and identification of these responses 01:16:14 ack ato 01:16:46 q+ 01:17:06 ato: I don't think we can use JSON RPC. We are fundamentally constrained by existing clients. We need to be able to proxy existing RPC clients, which would require a fundamental rewrite of all clients 01:17:27 ... we shouldn't change the fundamental transport protocol 01:17:49 ... there's a corpus of clients which already use a protocol. This would be an unnecessary change 01:18:09 jgraham: what's the advantage of using JSON RPC, as opposed to the CDP version of the JSON that's being carried over? 01:18:37 brrian: it's a spec. I don't want to be required to conform to weird CDP bugs 01:19:56 q? 01:20:09 q- 01:20:29 ato: I would like to use a more well-defined message formatting, but I'm not sure the JSON RPC is the right answer. We should nail down the specifics before we do this. JSON RPC is a good guidepost, but we shouldn't assume it will solve all our problems, and may require additional specprose for how to define these things, and it may get very complicated very quickly 01:20:53 lukebjerring: can we have a translation layer? this would allow us to transition clients over time 01:21:20 q+ 01:21:39 CalebRouleau: what problems are there in the CDP right now that would prevent us from using it as a guideline? 01:22:24 simonstewart: we shouldn't start from an existing implementation and work backward, we should start with what we need and define the protocol as required 01:22:25 q+ 01:22:41 q+ 01:23:28 jgraham: the mistake we've made is "making small changes to things that work, and spending years fostering adoption", when we should instead focus on solving user problems, as evidenced by the heavy usage of CDP 01:23:55 q? 01:24:45 jgraham: we're making a mistake by talking about the transport layer, in that we're missing the actual use case. Let's defer making a resolution at the moment, because we haven't moved through the conversation enough, guided by real knowledge of the existing issues 01:24:47 ack Hexcles 01:26:01 ack cb 01:26:04 Hexcles: the WD spec is still a single-direction protocol. We haven't started to talk about how to make them truly bi-di, but there's nothing in the JSON RPC spec that directly encourages bi-directional communication 01:26:22 s/the WD spec/the JSON RPC spec/ 01:27:26 cb: adoption of tools is a whole other problem. Cypress, Puppeteer, etc., all use the CDP itself, so making the spec more friendly to the CDP would be a benefit to the spec, and we'd be missing a lot of use cases by ignoring it 01:27:30 ack brrian 01:28:11 Zakim close the queue 01:28:29 zghadyali has joined #webdriver 01:28:45 brrian: there's a lot of concern about the difference between what we want and what JSON RPC offers. I've personally found it to be quite easy to follow, and made no practical difference to the amount of change. The benefit was that we can say we conform, and that our packets will be predictable 01:29:07 brrian: having written 3 implementations in 3 languages, I can say it's trivial 01:30:02 jgraham: JSON RPC is roughly the shape of how the transport protocol should go, but there are particulars to its adoption 01:30:38 ato: we have concerns about version pinning as well as the server-side events as they come across. I have ideas for a transition plan, but we need to address the concerns before we can resolve 01:31:01 jgraham: we agree that we can't adopt the JSON RPC spec without having studied it further 01:31:03 Hexcles has joined #webdriver 01:32:56 zcorpan has joined #webdriver 01:33:26 kdzwinel has joined #webdriver 01:41:43 zcorpan has joined #webdriver 01:47:35 zcorpan has joined #webdriver 01:50:30 diervo has joined #webdriver 01:55:13 diervo has joined #webdriver 01:57:24 bwald_ has joined #webdriver 01:59:50 titusfortner has joined #webdriver 02:00:28 Hexcles has joined #webdriver 02:01:37 bwald_ has joined #webdriver 02:01:55 zcorpan has joined #webdriver 02:01:58 simonstewart has joined #webdriver 02:03:17 kdzwinel has joined #webdriver 02:03:32 q+ 02:04:15 ella has joined #webdriver 02:04:28 AutomatedTester: start from .. transports roughly agreed 02:04:42 CalebRouleau has joined #webdriver 02:04:48 ack simonstewart 02:04:59 mmerrell has joined #webdriver 02:05:14 q+ 02:05:18 simonstewart: How to send references to browsing contexts, frames 02:05:28 ... something like ExecuteScript 02:05:59 CalebRouleau: WD curently has notion of "you are attached this to this specific handle" 02:06:24 q+ 02:06:32 simonstewart: I think we will allow to communicate with multiple handles 02:06:53 ... [example of communication with ServiceWorker] 02:07:22 CalebRouleau: send to any browsing context, and get events back from any? 02:07:26 simonstewart: yes 02:07:39 ack 02:07:41 q? 02:07:47 ack CalebRouleau 02:07:47 ack CalebRouleau 02:08:28 ato: "control" messages, example, if you want to get browser-internal logs, that might not require a target ID 02:09:07 q+ 02:09:32 ... some commands make sense in a global scope, some make sense in scope of a single browsing context 02:10:31 jgraham: JS realms, global object is a JS realm 02:10:40 ack bwald_ 02:11:49 ack jgraham 02:12:14 jgraham: important to distinguish between browsing contexts and targets 02:12:32 q? 02:12:37 q+ 02:12:47 ... it's important to be able to target more than just window globals 02:13:06 ... [inject script case] 02:13:36 jgraham: should be possible to specify either a browsing context, or a target, or 02:13:39 ack drousso 02:13:40 q+ 02:13:55 drousso: similar to how Web Inspector already works 02:14:05 q+ 02:14:05 ... we include a target ID in every message 02:14:09 ack brrian 02:14:23 q? 02:14:27 q+ 02:14:32 ack ato 02:14:48 brrian: SafariDriver has an internal protocol in which the browsing context is passed around with every command 02:15:03 ato: what we have now requires a lot of context-switching 02:15:21 ... that makes sense in WebDriver's view of the world 02:15:39 ... [which maps to how a user sees and does things] 02:15:54 q+ 02:15:55 ... but I have a sense that the bidi protocol is a bit lower than that 02:16:01 q+ 02:16:28 ... so some of the things we have held true so far might no longer hold true in the bidi protocol 02:17:13 ato: ability to associate a message going over bidi with a specific browsing context, without needing to switch into that context 02:18:38 ack CalebRouleau 02:18:43 q- 02:18:44 ack brrian 02:19:06 RESOLUTION: It should be possible for command request messages to target a particular target/browsing context. 02:19:07 q+ 02:19:38 q+ 02:19:40 brrian: for random clients, let's make it as foolproof as possible 02:19:57 RRSAgent, make minutes 02:19:57 I have made the request to generate https://www.w3.org/2019/09/20-webdriver-minutes.html MikeSmith 02:20:53 ack simonstewart 02:21:16 simonstewart: we want to reformulate WebDriver on top of the bidi communication thing 02:21:59 q? 02:22:16 ... have world where we can do everything in the same protocol 02:22:38 ack ato 02:22:58 i/transports roughly agreed/scribenick: MikeSmith 02:23:32 ato: we should continue to bear in mind that we enable that kind of programming model that is being use by, for example, Puppeteer 02:23:43 ... message indexing is really important 02:24:34 ... we would agree that every request wof this bidi protocol should have exactly one response 02:24:56 ... that case is not implicit in JSON-RPC 02:25:44 q? 02:25:51 RRSAgent, make minutes 02:25:51 I have made the request to generate https://www.w3.org/2019/09/20-webdriver-minutes.html MikeSmith 02:26:42 nao_watanabe_access has joined #webdriver 02:27:02 ato: additional complication of CDP, the fact that does not have a target that is not a browsing context but is instead an execution context 02:27:35 s/that does not have/that has 02:28:06 ato: you get an event back telling you that a new execution context has been created 02:28:15 q? 02:28:17 AutomatedTester: what is left to do? 02:28:48 jgraham: so bunch of stuff we been doing by reference to CDP 02:29:01 ... wrapping messages to root them to a target 02:29:19 ... we too want to do it that way? 02:29:30 q+ 02:29:50 simonstewart: new thing in CDP, where yo uhave a session ID and you prepart a message and send to it a single WebSocket connection 02:30:03 drousso: we are similar to that 02:30:22 jgraham: do we weant to replicate that design? 02:30:28 simonstewart: no 02:30:47 jgraham: artifact of the way that devtools needed to operate 02:31:04 q+ 02:31:08 q+ 02:32:11 jgraham: the reason they added that wrapper way is because they did not want to change the existing protocol they had, which assumed a single browsing context 02:32:56 simonstewart: looks definitely like a historical artifact 02:33:03 ... double-encoding JSON 02:33:08 CalebRouleau: gross 02:33:25 ... we don't want that 02:33:51 ack brrian 02:34:15 q+ 02:34:18 brrian: we have a similar implementation detail 02:34:22 q+ 02:34:25 q- 02:34:45 ... I don't think we should expose any of that 02:35:22 CalebRouleau: target will be consistent across a browsing context 02:35:37 ... not just doing what CDP does 02:36:23 jgraham: do we adopt the syntactic pattern that already exists? or do we do something more sane? 02:36:56 brrian: the existing devtools mechanism comes from things that are specific to debugging 02:37:15 q- 02:37:24 ... and we are not making this feature for debugging needs 02:37:35 ack bwald_ 02:37:52 q- 02:37:53 bwald_: process-switching is an implementation detail 02:38:33 ... I don't see any reason to abandon the current model of the browser as we are using for WebDriver now 02:38:39 q? 02:38:43 ack ato 02:38:54 q+ 02:39:00 ato: conflation of targets and execution contexts 02:39:11 https://firefox-source-docs.mozilla.org/remote/Architecture.html 02:39:18 .. Firefox is working on a implementation of CDP 02:39:29 ... see the doc as the URL above 02:39:53 ... a target can be a tab (as opposed to a browsing context) 02:40:12 ... you can route individual messages using the session ID 02:40:57 q+ 02:41:06 ack simonstewart 02:41:56 simonstewart: so we connect, and the thing we want to do is, register a listener (say) 02:42:23 ... we will have a command name, a list of arguments 02:42:43 q? 02:42:45 ... how do we say which execution context it will be run in? 02:43:12 JohnChen: WebDriver process is normally implicit 02:43:24 ... but in bidi it is is different 02:44:17 simonstewart: context ID 02:44:36 ato: historially CDP did not support site isolation 02:44:56 ... so there are artifacts in it that were based on assuming that 02:45:51 q? 02:45:52 q+ 02:46:31 ato: important thing is for the context ID to be a serializable value that can be passed around 02:46:47 simonstewart: we haev a window handle, but not for a frame 02:46:52 q+ 02:46:53 jgraham: we do 02:47:59 ato: we have this is the spec but not implemented 02:49:05 ato: CDP is both an HTTP API and a socket API 02:49:41 ato: can auto-attach 02:50:16 ... (which changes the implicit target, btw, and not sure we want that part of it) 02:50:24 q? 02:51:07 ato: a service worker is not a browsing context 02:51:52 zcorpan has joined #webdriver 02:52:17 ato: we are inventing a super-abstraction above browsing contexts 02:52:23 ack bwald_ 02:52:44 bwald_: getting an event back to the client when a mutation occurs 02:53:06 ... maybe need a way to pass in a function go get message back to client 02:55:00 ack ato 02:56:49 ato: how to identify JS object, we should talk about 02:57:37 ... in CDP you can return anything; for example, a JS object 02:59:13 q- 02:59:39 simonstewart: element ID in the WebDriver spec is because we were limited by the serialization mechanism 03:00:35 q+ 03:01:04 ack simonstewart 03:01:21 simonstewart: element IDs are the JS object reference 03:01:38 ... window handle is the target iD for browser context 03:01:53 falken has joined #webdriver 03:02:16 bwald_: message passing? 03:02:40 ... supply a postMessage ID 03:02:50 ato: is that in CDP? 03:02:53 we're also introducing a new id for the frame 03:03:04 CalebRouleau: is there a reason CDP does not have this? 03:03:30 drousso: in devtools we have direct access to the engine 03:03:42 CalebRouleau: how does Puppeteer do this? 03:03:44 Simon, can you summarize the last point about the frame ID so that we have your telling on record? 03:04:04 ato: you can pass in fuctions, inner functions, or Promises 03:05:08 bwald_: CDP pollutes the global namespace [to do the similar thing] 03:05:53 Summary: Add a new "get context" function to existing webdriver. If the "current context" is a top level browsing context, this will return the current window handle. For a frame, it's "something" that we create. In both cases, the "context id" can be passed to bidi to use as a target id 03:05:58 q+ 03:06:03 thanks 03:07:03 ato: current CDP primitive is conceptually very similar to what we were are already doing in WebDriver 03:07:24 ... primitive for script execution without a lifetime 03:07:50 simonstewart: there is a no synchronous thing for this in CDP 03:07:59 jgraham: there is no blocking 03:08:55 ato: another model is the Promise style [in addition to return-by-value] 03:09:59 simonstewart: get the communication part sorted out first 03:10:24 jgraham: existing clients provida a way to create a custom event stream in JS? 03:10:37 ato: there is a way in Puppeteer 03:12:23 [discussion of handling of bootstrap scripts] 03:14:34 jgraham: this is how extensions work, basically 03:14:42 ... so conceptually is already exists 03:14:55 ack ato 03:15:08 zcorpan has joined #webdriver 03:16:25 ato: connections in the API, for a script injection, for a single browsing context, there soucld be multiple execution context 03:16:43 ... some execution contexts may be privileged 03:17:52 ato: each service worker can have mulitple JS realms? 03:18:01 s/?/ 03:18:13 jgraham: theoretically, yes, but in practice, no 03:19:01 q? 03:19:51 RRSAgent, make minutes 03:19:51 I have made the request to generate https://www.w3.org/2019/09/20-webdriver-minutes.html MikeSmith 03:20:17 simonstewart: if you send an element from the remote end to local end, how do you know which context it has come from? 03:21:01 ato: I don't think it does in CDP, but there is a way to query for it 03:21:17 simonstewart: ... which is very inefficient 03:21:35 bwald_: included in the event, is how we should do it 03:22:21 simonste_ has joined #webdriver 03:22:55 simonst__ has joined #webdriver 03:23:01 CalebRouleau: to implement this in ChromeDriver will be a pain and inefficient 03:23:13 [JohnChen explains why] 03:24:38 present+ 03:25:48 s/simonst__// 03:26:01