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