IRC log of webdriver on 2019-09-20
Timestamps are in UTC.
- 00:31:30 [RRSAgent]
- RRSAgent has joined #webdriver
- 00:31:30 [RRSAgent]
- logging to https://www.w3.org/2019/09/20-webdriver-irc
- 00:31:36 [Zakim]
- Zakim has joined #webdriver
- 00:31:57 [jgraham]
- RRSAgent, this meeting spans midnight
- 00:32:15 [Hexcles]
- Hexcles has joined #webdriver
- 00:32:31 [AutomatedTester]
- Chair: AutomatedTester
- 00:32:38 [AutomatedTester]
- present+
- 00:32:41 [titusfortner]
- titusfortner has joined #webdriver
- 00:33:07 [jgraham]
- agenda: https://docs.google.com/document/d/1gUm7Be-akW2-4mjr15cnZlzwoAfOlfL7b3tWCDrb1Jg/edit#
- 00:33:10 [jgraham]
- present+
- 00:33:13 [simonstewart]
- present+
- 00:33:17 [bwalderman]
- present+
- 00:33:51 [JohnChen]
- JohnChen has joined #webdriver
- 00:33:54 [AutomatedTester]
- Meeting: Browser Tools- and Testing WG, Day 2, TPAC 2019, Fukuoka
- 00:34:09 [AutomatedTester]
- rrsagent, this meeting spans midnight
- 00:34:31 [jgraham]
- RRSAgent, make logs public
- 00:34:34 [Hexcles]
- present+
- 00:34:40 [jgraham]
- RRSAgent, create minutes v2
- 00:34:41 [RRSAgent]
- I have made the request to generate https://www.w3.org/2019/09/20-webdriver-minutes.html jgraham
- 00:34:48 [mmerrell]
- mmerrell has joined #webdriver
- 00:34:49 [mmerrell]
- present+
- 00:35:15 [JohnChen]
- present+
- 00:35:16 [drousso]
- drousso has joined #webdriver
- 00:36:36 [ato]
- present+
- 00:36:45 [ato]
- Chair: AutomatedTester
- 00:36:52 [CalebRouleau]
- CalebRouleau has joined #webdriver
- 00:37:32 [bwald_]
- bwald_ has joined #webdriver
- 00:39:26 [drousso]
- present+
- 00:40:41 [diemol]
- present+
- 00:41:51 [mmerrell]
- topic: bi-directional communication
- 00:41:52 [CalebRouleau]
- present+
- 00:42:02 [ato]
- https://docs.google.com/spreadsheets/d/1mZGuKR4SR6HGhqf4wTJQg6eJQBkqnP4G3ibkPTIP_1Q/edit#gid=2126300658
- 00:42:09 [titusfortner]
- present+
- 00:42:12 [mmerrell]
- everyone should mark themself present
- 00:42:31 [MikeSmith]
- present+
- 00:42:33 [brrian]
- present+
- 00:42:37 [scheib]
- scheib has joined #webdriver
- 00:42:37 [simonstewart]
- I hast marked mineself as being present
- 00:42:38 [zghadyali]
- zghadyali has joined #webdriver
- 00:42:38 [cb]
- present+
- 00:42:39 [JohnJansen]
- present+
- 00:42:40 [zghadyali]
- present+
- 00:42:45 [scheib]
- present+
- 00:42:53 [mmerrell]
- AutomatedTester: continuation of the bi-di talk. centered around proper examples
- 00:43:14 [mmerrell]
- ... need to start from implementation and go backward
- 00:43:14 [bwald_]
- bwald_ has joined #webdriver
- 00:43:21 [JohnChen]
- q+
- 00:43:21 [bwald_]
- present+
- 00:43:27 [mmerrell]
- AutomatedTester: start with "loading", how we'd do navigation
- 00:43:43 [mmerrell]
- CalebRouleau: first thing would be to target a navigation (across tabs)
- 00:44:02 [brrian]
- q+
- 00:44:12 [AutomatedTester]
- ack JohnChen
- 00:44:33 [mmerrell]
- 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 [mmerrell]
- .. page.navigate() has 2 params, the tab (the target) and the URL
- 00:45:16 [simonstewart]
- https://chromedevtools.github.io/devtools-protocol/tot/Page#method-navigate
- 00:45:16 [kdzwinel]
- kdzwinel has joined #webdriver
- 00:46:41 [mmerrell]
- ... 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 [mmerrell]
- ... page.frameStopLoading event indicates the loading is done
- 00:47:12 [AutomatedTester]
- q?
- 00:47:17 [jgraham]
- scribenick: mmerrell
- 00:47:20 [mmerrell]
- ... chrome monitors for these events, and makes decisions based on that. This is how loading happens with CDP
- 00:47:27 [mmerrell]
- brrian: why are we talking about this?
- 00:47:37 [mmerrell]
- AutomatedTester: we're trying to use an example of a command, and working backward
- 00:47:37 [Hexcles]
- s/frameStopLoading/frameStoppedLoading/
- 00:47:46 [AutomatedTester]
- ack brrian
- 00:47:51 [mmerrell]
- brrian: is this part of the use case we talked about yesterday?
- 00:47:52 [bwald_]
- q+
- 00:47:55 [mmerrell]
- JohnChen: yes
- 00:48:07 [mmerrell]
- brrian: this seems like a duplicate
- 00:48:23 [mmerrell]
- jgraham: if the use cases don't include this the use cases are wrong
- 00:48:39 [AutomatedTester]
- RRSAgent: make minutes
- 00:48:39 [RRSAgent]
- I have made the request to generate https://www.w3.org/2019/09/20-webdriver-minutes.html AutomatedTester
- 00:48:56 [bwald_]
- q-
- 00:49:09 [mmerrell]
- 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]
- boaz has joined #webdriver
- 00:49:58 [simonstewart]
- q+
- 00:50:03 [mmerrell]
- 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 [JohnChen]
- q?
- 00:50:29 [JohnChen]
- q+
- 00:50:47 [mmerrell]
- brrian: this isn't part of the use cases
- 00:51:18 [mmerrell]
- 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 [mmerrell]
- lukebjerring: it's easier to start with a use case that involves every part of the protocol
- 00:52:29 [mmerrell]
- jgraham: nav is a necessary component of a rewrite of the protocol
- 00:52:41 [mmerrell]
- simonstewart: it's not necessary, but it's already in there
- 00:52:53 [simonstewart]
- s/but it's/and it's/
- 00:52:54 [mmerrell]
- jgraham: but we've already demonstrated that the discussion has been incomplete
- 00:53:40 [mmerrell]
- 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 [AutomatedTester]
- q?
- 00:54:13 [AutomatedTester]
- ack simonstewart
- 00:54:17 [drousso]
- q+
- 00:54:20 [AutomatedTester]
- ack JohnChen
- 00:54:23 [mmerrell]
- JohnChen: one use case was the request modification (intercept), which has been covered in the CDP
- 00:54:24 [simonstewart]
- q+
- 00:55:30 [mmerrell]
- 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 [AutomatedTester]
- ack drousso
- 00:56:00 [jgraham]
- q+
- 00:56:08 [CalebRouleau]
- q+
- 00:56:11 [mmerrell]
- 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 [bwald_]
- q+
- 00:57:18 [mmerrell]
- ... 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 [mmerrell]
- JohnChen: whatever script is running on the page disappears once the load event changes
- 00:57:54 [simonstewart]
- q-
- 00:58:14 [mmerrell]
- drousso: you should be able to send a script to the driver, which executes just prior to a load event
- 00:58:43 [mmerrell]
- CalebRouleau: but JavaScript can't do everything we want, so we need to talk about it as a separate issue
- 00:59:49 [mmerrell]
- 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 [mmerrell]
- CalebRouleau: this is getting too meta, so I suggest getting back to concrete examples
- 01:00:13 [AutomatedTester]
- q?
- 01:00:43 [bwald_]
- q-
- 01:01:10 [ato]
- q+
- 01:01:43 [mmerrell]
- CalebRouleau: we should talk about logging, which will give us the context that fosters agreement on a framework or bi-di
- 01:02:04 [JohnJansen]
- q?
- 01:02:27 [brrian]
- q+
- 01:02:31 [bwald_]
- q+
- 01:02:38 [mmerrell]
- 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 [ato]
- q-
- 01:03:12 [simonstewart]
- q+
- 01:03:19 [mmerrell]
- 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 [mmerrell]
- bwald_: that will include transports, correct?
- 01:03:56 [AutomatedTester]
- q?
- 01:03:57 [mmerrell]
- jgraham: yes, but there's a risk that we're leaving too much out
- 01:04:05 [mmerrell]
- [general agreement on moving forward]
- 01:04:18 [mmerrell]
- simonstewart: we should also include the handshake
- 01:04:30 [JohnJansen]
- 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_]
- Hexcles_ has joined #webdriver
- 01:04:45 [mmerrell]
- jgraham: has the position changed since TPAC 2018? the conclusion was around a capability that included "bi-di". Has that changed?
- 01:05:31 [AutomatedTester]
- q?q?
- 01:05:38 [mmerrell]
- 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 [mmerrell]
- simonstewart: the top-level return payload should include the "upgrade URL", but which can be re-written
- 01:07:18 [ato]
- q?
- 01:08:27 [mmerrell]
- 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 [RRSAgent]
- I have made the request to generate https://www.w3.org/2019/09/20-webdriver-minutes.html ato
- 01:09:45 [AutomatedTester]
- scribenick: automatedtester
- 01:09:51 [simonstewart]
- q?
- 01:09:59 [jgraham]
- q-
- 01:10:10 [CalebRouleau]
- q-
- 01:10:25 [AutomatedTester]
- CalebRouleau: are we going to be doing 1 URL or multiple
- 01:10:29 [AutomatedTester]
- simonstewart: 1
- 01:11:10 [AutomatedTester]
- ack brrian
- 01:11:15 [brrian]
- https://www.jsonrpc.org/specification
- 01:11:20 [simonstewart]
- q-
- 01:11:33 [mmerrell]
- scribenick: mmerrell
- 01:12:34 [mmerrell]
- 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 [AutomatedTester]
- q?
- 01:13:01 [mmerrell]
- 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 [mmerrell]
- jgraham: is this close to existing implementations?
- 01:13:24 [mmerrell]
- bwald_: we should start with JSON RPC. I second
- 01:13:24 [AutomatedTester]
- ack bwald_
- 01:13:45 [mmerrell]
- ... CDP is basically already JSON RPC, only missing a couple things
- 01:13:54 [simonstewart]
- q-
- 01:14:28 [mmerrell]
- 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 [mmerrell]
- bwald_: it's proposed that the bi-directional WebDriver protocol uses JSON RPC
- 01:15:28 [mmerrell]
- jgraham: we would need to study the standard more before agreeing to this
- 01:15:39 [ato]
- q+
- 01:16:11 [mmerrell]
- 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 [AutomatedTester]
- ack ato
- 01:16:46 [simonstewart]
- q+
- 01:17:06 [mmerrell]
- 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 [mmerrell]
- ... we shouldn't change the fundamental transport protocol
- 01:17:49 [mmerrell]
- ... there's a corpus of clients which already use a protocol. This would be an unnecessary change
- 01:18:09 [mmerrell]
- 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 [mmerrell]
- brrian: it's a spec. I don't want to be required to conform to weird CDP bugs
- 01:19:56 [AutomatedTester]
- q?
- 01:20:09 [simonstewart]
- q-
- 01:20:29 [mmerrell]
- 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 [mmerrell]
- lukebjerring: can we have a translation layer? this would allow us to transition clients over time
- 01:21:20 [Hexcles]
- q+
- 01:21:39 [mmerrell]
- CalebRouleau: what problems are there in the CDP right now that would prevent us from using it as a guideline?
- 01:22:24 [mmerrell]
- 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 [cb]
- q+
- 01:22:41 [brrian]
- q+
- 01:23:28 [mmerrell]
- 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 [simonstewart]
- q?
- 01:24:45 [mmerrell]
- 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 [AutomatedTester]
- ack Hexcles
- 01:26:01 [AutomatedTester]
- ack cb
- 01:26:04 [mmerrell]
- 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 [Hexcles]
- s/the WD spec/the JSON RPC spec/
- 01:27:26 [mmerrell]
- 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 [AutomatedTester]
- ack brrian
- 01:28:11 [AutomatedTester]
- Zakim close the queue
- 01:28:29 [zghadyali]
- zghadyali has joined #webdriver
- 01:28:45 [mmerrell]
- 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 [mmerrell]
- brrian: having written 3 implementations in 3 languages, I can say it's trivial
- 01:30:02 [mmerrell]
- jgraham: JSON RPC is roughly the shape of how the transport protocol should go, but there are particulars to its adoption
- 01:30:38 [mmerrell]
- 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 [mmerrell]
- jgraham: we agree that we can't adopt the JSON RPC spec without having studied it further
- 01:31:03 [Hexcles]
- Hexcles has joined #webdriver
- 01:32:56 [zcorpan]
- zcorpan has joined #webdriver
- 01:33:26 [kdzwinel]
- kdzwinel has joined #webdriver
- 01:41:43 [zcorpan]
- zcorpan has joined #webdriver
- 01:47:35 [zcorpan]
- zcorpan has joined #webdriver
- 01:50:30 [diervo]
- diervo has joined #webdriver
- 01:55:13 [diervo]
- diervo has joined #webdriver
- 01:57:24 [bwald_]
- bwald_ has joined #webdriver
- 01:59:50 [titusfortner]
- titusfortner has joined #webdriver
- 02:00:28 [Hexcles]
- Hexcles has joined #webdriver
- 02:01:37 [bwald_]
- bwald_ has joined #webdriver
- 02:01:55 [zcorpan]
- zcorpan has joined #webdriver
- 02:01:58 [simonstewart]
- simonstewart has joined #webdriver
- 02:03:17 [kdzwinel]
- kdzwinel has joined #webdriver
- 02:03:32 [simonstewart]
- q+
- 02:04:15 [ella]
- ella has joined #webdriver
- 02:04:28 [MikeSmith]
- AutomatedTester: start from .. transports roughly agreed
- 02:04:42 [CalebRouleau]
- CalebRouleau has joined #webdriver
- 02:04:48 [AutomatedTester]
- ack simonstewart
- 02:04:59 [mmerrell]
- mmerrell has joined #webdriver
- 02:05:14 [CalebRouleau]
- q+
- 02:05:18 [MikeSmith]
- simonstewart: How to send references to browsing contexts, frames
- 02:05:28 [MikeSmith]
- ... something like ExecuteScript
- 02:05:59 [MikeSmith]
- CalebRouleau: WD curently has notion of "you are attached this to this specific handle"
- 02:06:24 [bwald_]
- q+
- 02:06:32 [MikeSmith]
- simonstewart: I think we will allow to communicate with multiple handles
- 02:06:53 [MikeSmith]
- ... [example of communication with ServiceWorker]
- 02:07:22 [MikeSmith]
- CalebRouleau: send to any browsing context, and get events back from any?
- 02:07:26 [MikeSmith]
- simonstewart: yes
- 02:07:39 [CalebRouleau]
- ack
- 02:07:41 [CalebRouleau]
- q?
- 02:07:47 [AutomatedTester]
- ack CalebRouleau
- 02:07:47 [CalebRouleau]
- ack CalebRouleau
- 02:08:28 [MikeSmith]
- ato: "control" messages, example, if you want to get browser-internal logs, that might not require a target ID
- 02:09:07 [jgraham]
- q+
- 02:09:32 [MikeSmith]
- ... some commands make sense in a global scope, some make sense in scope of a single browsing context
- 02:10:31 [MikeSmith]
- jgraham: JS realms, global object is a JS realm
- 02:10:40 [AutomatedTester]
- ack bwald_
- 02:11:49 [AutomatedTester]
- ack jgraham
- 02:12:14 [MikeSmith]
- jgraham: important to distinguish between browsing contexts and targets
- 02:12:32 [drousso]
- q?
- 02:12:37 [drousso]
- q+
- 02:12:47 [MikeSmith]
- ... it's important to be able to target more than just window globals
- 02:13:06 [MikeSmith]
- ... [inject script case]
- 02:13:36 [MikeSmith]
- jgraham: should be possible to specify either a browsing context, or a target, or
- 02:13:39 [AutomatedTester]
- ack drousso
- 02:13:40 [brrian]
- q+
- 02:13:55 [MikeSmith]
- drousso: similar to how Web Inspector already works
- 02:14:05 [ato]
- q+
- 02:14:05 [MikeSmith]
- ... we include a target ID in every message
- 02:14:09 [AutomatedTester]
- ack brrian
- 02:14:23 [CalebRouleau]
- q?
- 02:14:27 [CalebRouleau]
- q+
- 02:14:32 [AutomatedTester]
- ack ato
- 02:14:48 [MikeSmith]
- brrian: SafariDriver has an internal protocol in which the browsing context is passed around with every command
- 02:15:03 [MikeSmith]
- ato: what we have now requires a lot of context-switching
- 02:15:21 [MikeSmith]
- ... that makes sense in WebDriver's view of the world
- 02:15:39 [MikeSmith]
- ... [which maps to how a user sees and does things]
- 02:15:54 [brrian]
- q+
- 02:15:55 [MikeSmith]
- ... but I have a sense that the bidi protocol is a bit lower than that
- 02:16:01 [simonstewart]
- q+
- 02:16:28 [MikeSmith]
- ... so some of the things we have held true so far might no longer hold true in the bidi protocol
- 02:17:13 [MikeSmith]
- ato: ability to associate a message going over bidi with a specific browsing context, without needing to switch into that context
- 02:18:38 [jgraham]
- ack CalebRouleau
- 02:18:43 [simonstewart]
- q-
- 02:18:44 [jgraham]
- ack brrian
- 02:19:06 [ato]
- RESOLUTION: It should be possible for command request messages to target a particular target/browsing context.
- 02:19:07 [simonstewart]
- q+
- 02:19:38 [ato]
- q+
- 02:19:40 [MikeSmith]
- brrian: for random clients, let's make it as foolproof as possible
- 02:19:57 [MikeSmith]
- RRSAgent, make minutes
- 02:19:57 [RRSAgent]
- I have made the request to generate https://www.w3.org/2019/09/20-webdriver-minutes.html MikeSmith
- 02:20:53 [AutomatedTester]
- ack simonstewart
- 02:21:16 [MikeSmith]
- simonstewart: we want to reformulate WebDriver on top of the bidi communication thing
- 02:21:59 [CalebRouleau]
- q?
- 02:22:16 [MikeSmith]
- ... have world where we can do everything in the same protocol
- 02:22:38 [AutomatedTester]
- ack ato
- 02:22:58 [MikeSmith]
- i/transports roughly agreed/scribenick: MikeSmith
- 02:23:32 [MikeSmith]
- 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 [MikeSmith]
- ... message indexing is really important
- 02:24:34 [MikeSmith]
- ... we would agree that every request wof this bidi protocol should have exactly one response
- 02:24:56 [MikeSmith]
- ... that case is not implicit in JSON-RPC
- 02:25:44 [simonstewart]
- q?
- 02:25:51 [MikeSmith]
- RRSAgent, make minutes
- 02:25:51 [RRSAgent]
- I have made the request to generate https://www.w3.org/2019/09/20-webdriver-minutes.html MikeSmith
- 02:26:42 [nao_watanabe_access]
- nao_watanabe_access has joined #webdriver
- 02:27:02 [MikeSmith]
- 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 [MikeSmith]
- s/that does not have/that has
- 02:28:06 [MikeSmith]
- ato: you get an event back telling you that a new execution context has been created
- 02:28:15 [CalebRouleau]
- q?
- 02:28:17 [MikeSmith]
- AutomatedTester: what is left to do?
- 02:28:48 [MikeSmith]
- jgraham: so bunch of stuff we been doing by reference to CDP
- 02:29:01 [MikeSmith]
- ... wrapping messages to root them to a target
- 02:29:19 [MikeSmith]
- ... we too want to do it that way?
- 02:29:30 [brrian]
- q+
- 02:29:50 [MikeSmith]
- 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 [MikeSmith]
- drousso: we are similar to that
- 02:30:22 [MikeSmith]
- jgraham: do we weant to replicate that design?
- 02:30:28 [MikeSmith]
- simonstewart: no
- 02:30:47 [MikeSmith]
- jgraham: artifact of the way that devtools needed to operate
- 02:31:04 [CalebRouleau]
- q+
- 02:31:08 [simonstewart]
- q+
- 02:32:11 [MikeSmith]
- 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 [MikeSmith]
- simonstewart: looks definitely like a historical artifact
- 02:33:03 [MikeSmith]
- ... double-encoding JSON
- 02:33:08 [MikeSmith]
- CalebRouleau: gross
- 02:33:25 [MikeSmith]
- ... we don't want that
- 02:33:51 [AutomatedTester]
- ack brrian
- 02:34:15 [bwald_]
- q+
- 02:34:18 [MikeSmith]
- brrian: we have a similar implementation detail
- 02:34:22 [ato]
- q+
- 02:34:25 [simonstewart]
- q-
- 02:34:45 [MikeSmith]
- ... I don't think we should expose any of that
- 02:35:22 [MikeSmith]
- CalebRouleau: target will be consistent across a browsing context
- 02:35:37 [MikeSmith]
- ... not just doing what CDP does
- 02:36:23 [MikeSmith]
- jgraham: do we adopt the syntactic pattern that already exists? or do we do something more sane?
- 02:36:56 [MikeSmith]
- brrian: the existing devtools mechanism comes from things that are specific to debugging
- 02:37:15 [CalebRouleau]
- q-
- 02:37:24 [MikeSmith]
- ... and we are not making this feature for debugging needs
- 02:37:35 [AutomatedTester]
- ack bwald_
- 02:37:52 [simonstewart]
- q-
- 02:37:53 [MikeSmith]
- bwald_: process-switching is an implementation detail
- 02:38:33 [MikeSmith]
- ... I don't see any reason to abandon the current model of the browser as we are using for WebDriver now
- 02:38:39 [jgraham]
- q?
- 02:38:43 [AutomatedTester]
- ack ato
- 02:38:54 [simonstewart]
- q+
- 02:39:00 [MikeSmith]
- ato: conflation of targets and execution contexts
- 02:39:11 [ato]
- https://firefox-source-docs.mozilla.org/remote/Architecture.html
- 02:39:18 [MikeSmith]
- .. Firefox is working on a implementation of CDP
- 02:39:29 [MikeSmith]
- ... see the doc as the URL above
- 02:39:53 [MikeSmith]
- ... a target can be a tab (as opposed to a browsing context)
- 02:40:12 [MikeSmith]
- ... you can route individual messages using the session ID
- 02:40:57 [jgraham]
- q+
- 02:41:06 [AutomatedTester]
- ack simonstewart
- 02:41:56 [MikeSmith]
- simonstewart: so we connect, and the thing we want to do is, register a listener (say)
- 02:42:23 [MikeSmith]
- ... we will have a command name, a list of arguments
- 02:42:43 [AutomatedTester]
- q?
- 02:42:45 [MikeSmith]
- ... how do we say which execution context it will be run in?
- 02:43:12 [MikeSmith]
- JohnChen: WebDriver process is normally implicit
- 02:43:24 [MikeSmith]
- ... but in bidi it is is different
- 02:44:17 [MikeSmith]
- simonstewart: context ID
- 02:44:36 [MikeSmith]
- ato: historially CDP did not support site isolation
- 02:44:56 [MikeSmith]
- ... so there are artifacts in it that were based on assuming that
- 02:45:51 [AutomatedTester]
- q?
- 02:45:52 [bwald_]
- q+
- 02:46:31 [MikeSmith]
- ato: important thing is for the context ID to be a serializable value that can be passed around
- 02:46:47 [MikeSmith]
- simonstewart: we haev a window handle, but not for a frame
- 02:46:52 [ato]
- q+
- 02:46:53 [MikeSmith]
- jgraham: we do
- 02:47:59 [MikeSmith]
- ato: we have this is the spec but not implemented
- 02:49:05 [MikeSmith]
- ato: CDP is both an HTTP API and a socket API
- 02:49:41 [MikeSmith]
- ato: can auto-attach
- 02:50:16 [MikeSmith]
- ... (which changes the implicit target, btw, and not sure we want that part of it)
- 02:50:24 [AutomatedTester]
- q?
- 02:51:07 [MikeSmith]
- ato: a service worker is not a browsing context
- 02:51:52 [zcorpan]
- zcorpan has joined #webdriver
- 02:52:17 [MikeSmith]
- ato: we are inventing a super-abstraction above browsing contexts
- 02:52:23 [AutomatedTester]
- ack bwald_
- 02:52:44 [MikeSmith]
- bwald_: getting an event back to the client when a mutation occurs
- 02:53:06 [MikeSmith]
- ... maybe need a way to pass in a function go get message back to client
- 02:55:00 [AutomatedTester]
- ack ato
- 02:56:49 [MikeSmith]
- ato: how to identify JS object, we should talk about
- 02:57:37 [MikeSmith]
- ... in CDP you can return anything; for example, a JS object
- 02:59:13 [jgraham]
- q-
- 02:59:39 [MikeSmith]
- simonstewart: element ID in the WebDriver spec is because we were limited by the serialization mechanism
- 03:00:35 [simonstewart]
- q+
- 03:01:04 [AutomatedTester]
- ack simonstewart
- 03:01:21 [MikeSmith]
- simonstewart: element IDs are the JS object reference
- 03:01:38 [MikeSmith]
- ... window handle is the target iD for browser context
- 03:01:53 [falken]
- falken has joined #webdriver
- 03:02:16 [MikeSmith]
- bwald_: message passing?
- 03:02:40 [MikeSmith]
- ... supply a postMessage ID
- 03:02:50 [MikeSmith]
- ato: is that in CDP?
- 03:02:53 [mmerrell]
- we're also introducing a new id for the frame
- 03:03:04 [MikeSmith]
- CalebRouleau: is there a reason CDP does not have this?
- 03:03:30 [MikeSmith]
- drousso: in devtools we have direct access to the engine
- 03:03:42 [MikeSmith]
- CalebRouleau: how does Puppeteer do this?
- 03:03:44 [mmerrell]
- Simon, can you summarize the last point about the frame ID so that we have your telling on record?
- 03:04:04 [MikeSmith]
- ato: you can pass in fuctions, inner functions, or Promises
- 03:05:08 [MikeSmith]
- bwald_: CDP pollutes the global namespace [to do the similar thing]
- 03:05:53 [simonstewart]
- 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 [ato]
- q+
- 03:06:03 [mmerrell]
- thanks
- 03:07:03 [MikeSmith]
- ato: current CDP primitive is conceptually very similar to what we were are already doing in WebDriver
- 03:07:24 [MikeSmith]
- ... primitive for script execution without a lifetime
- 03:07:50 [MikeSmith]
- simonstewart: there is a no synchronous thing for this in CDP
- 03:07:59 [MikeSmith]
- jgraham: there is no blocking
- 03:08:55 [MikeSmith]
- ato: another model is the Promise style [in addition to return-by-value]
- 03:09:59 [MikeSmith]
- simonstewart: get the communication part sorted out first
- 03:10:24 [MikeSmith]
- jgraham: existing clients provida a way to create a custom event stream in JS?
- 03:10:37 [MikeSmith]
- ato: there is a way in Puppeteer
- 03:12:23 [MikeSmith]
- [discussion of handling of bootstrap scripts]
- 03:14:34 [MikeSmith]
- jgraham: this is how extensions work, basically
- 03:14:42 [MikeSmith]
- ... so conceptually is already exists
- 03:14:55 [AutomatedTester]
- ack ato
- 03:15:08 [zcorpan]
- zcorpan has joined #webdriver
- 03:16:25 [MikeSmith]
- ato: connections in the API, for a script injection, for a single browsing context, there soucld be multiple execution context
- 03:16:43 [MikeSmith]
- ... some execution contexts may be privileged
- 03:17:52 [MikeSmith]
- ato: each service worker can have mulitple JS realms?
- 03:18:01 [MikeSmith]
- s/?/
- 03:18:13 [MikeSmith]
- jgraham: theoretically, yes, but in practice, no
- 03:19:01 [AutomatedTester]
- q?
- 03:19:51 [MikeSmith]
- RRSAgent, make minutes
- 03:19:51 [RRSAgent]
- I have made the request to generate https://www.w3.org/2019/09/20-webdriver-minutes.html MikeSmith
- 03:20:17 [MikeSmith]
- 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 [MikeSmith]
- ato: I don't think it does in CDP, but there is a way to query for it
- 03:21:17 [MikeSmith]
- simonstewart: ... which is very inefficient
- 03:21:35 [MikeSmith]
- bwald_: included in the event, is how we should do it
- 03:22:21 [simonste_]
- simonste_ has joined #webdriver
- 03:22:55 [simonst__]
- simonst__ has joined #webdriver
- 03:23:01 [MikeSmith]
- CalebRouleau: to implement this in ChromeDriver will be a pain and inefficient
- 03:23:13 [MikeSmith]
- [JohnChen explains why]
- 03:24:38 [simonst__]
- present+
- 03:25:48 [ato]
- s/simonst__//
- 03:26:01 [MikeSmith]
- JohnChen: have not found an efficient way to map element ID
- 03:26:07 [MikeSmith]
- CalebRouleau: in JS land
- 03:28:22 [MikeSmith]
- JohnChen: low-level, the IDs that devtools know about are not exposable to JS [in an easy way]
- 03:31:05 [MikeSmith]
- s/JS [in an easy way]/JS
- 03:31:43 [zghadyali]
- zghadyali has joined #webdriver
- 03:32:10 [MikeSmith]
- jgraham: when do runscript in CDP, you get back a reference to an object
- 03:32:27 [MikeSmith]
- ... but what WebDriver wants is not that
- 03:32:42 [MikeSmith]
- ... so you would need to query again to get what we would need
- 03:33:58 [MikeSmith]
- JohnChen: so we could do what we need but it will require additional roundtrips
- 03:34:17 [MikeSmith]
- drousso: similarly for us in Sfari
- 03:35:34 [MikeSmith]
- RRSAgent, make minutes
- 03:35:34 [RRSAgent]
- I have made the request to generate https://www.w3.org/2019/09/20-webdriver-minutes.html MikeSmith
- 03:36:57 [kdzwinel]
- kdzwinel has joined #webdriver
- 03:37:01 [Hexcles]
- Hexcles has joined #webdriver
- 04:01:27 [simonstewart]
- simonstewart has joined #webdriver
- 04:11:36 [kdzwinel]
- kdzwinel has joined #webdriver
- 04:14:23 [kdzwinel_]
- kdzwinel_ has joined #webdriver
- 04:15:05 [kdzwinel]
- kdzwinel has joined #webdriver
- 04:20:31 [bwald_]
- bwald_ has joined #webdriver
- 04:27:03 [Lan]
- Lan has joined #webdriver
- 04:29:32 [simonstewart]
- https://github.com/GoogleChrome/puppeteer/blob/master/lib/ExecutionContext.js#L142
- 04:29:51 [diemol]
- diemol has joined #webdriver
- 04:37:35 [Hexcles]
- Hexcles has joined #webdriver
- 04:38:19 [titusfortner]
- titusfortner has joined #webdriver
- 04:39:13 [boaz]
- boaz has joined #webdriver
- 04:39:39 [kdzwinel]
- kdzwinel has joined #webdriver
- 04:44:11 [kzms2]
- kzms2 has joined #webdriver
- 04:45:10 [jgraham]
- https://developer.mozilla.org/en-US/docs/Mozilla/Tech/Xray_vision
- 04:45:16 [zcorpan]
- zcorpan has joined #webdriver
- 04:46:48 [mmerrell]
- mmerrell has joined #webdriver
- 04:47:04 [mmerrell]
- scribenick: mmerrell
- 04:48:51 [drousso]
- drousso has joined #webdriver
- 04:49:14 [projector_webdriver]
- hello
- 04:49:15 [mmerrell]
- your name is brrian
- 04:49:17 [drousso]
- present+
- 04:49:25 [AutomatedTester]
- https://docs.google.com/document/d/1gUm7Be-akW2-4mjr15cnZlzwoAfOlfL7b3tWCDrb1Jg/edit#heading=h.f9zxnd3oxxm9
- 04:50:20 [mmerrell]
- topic: ato's comments on bidi
- 04:51:23 [mmerrell]
- ato: good progress was made this morning, but we need to make sure follow-up actions are taken in order to prevent a repeat conversation next year
- 04:51:50 [mmerrell]
- ... [ato takes an action to make some detailed proposals around these decisions]
- 04:52:18 [mmerrell]
- topic: long-running new session
- 04:52:53 [mmerrell]
- simonstewart: context: new session is synchronous--request new session, and the wait can be forever
- 04:53:11 [ato]
- ACTION: ato to draft proposal for the bi-di protocol interop terminology we discussed this morning