16:02:06 <RRSAgent> RRSAgent has joined #webdriver
16:02:06 <RRSAgent> logging to https://www.w3.org/2020/07/01-webdriver-irc
16:03:07 <jgraham> R
16:03:43 <jgraham> Zakim: This is Browser Tools and Testing
16:04:10 <AutomatedTester> meeting: WebDriver Bidi - July 2020
16:04:11 <jgraham> RRSAgent: make minutes
16:04:11 <RRSAgent> I have made the request to generate https://www.w3.org/2020/07/01-webdriver-minutes.html jgraham
16:04:22 <jgraham> RRSAgent: make logs public
16:04:29 <jgraham> present+ jgraham
16:04:31 <bwalderman> present+
16:04:32 <foolip> present+
16:04:33 <jimevans> jimevans has joined #webdriver
16:04:36 <mathiasbynens> present+
16:04:36 <AutomatedTester> Chair:AutomatedTester
16:04:39 <JohnJansen> present+
16:04:43 <simonstewart> simonstewart has joined #webdriver
16:04:48 <drousso> present+
16:04:54 <AutomatedTester> present+
16:04:56 <jimevans> present+
16:05:01 <simonstewart> present+
16:05:12 <AutomatedTester> Scribe: AutomatedTester
16:05:50 <JohnChen> JohnChen has joined #webdriver
16:06:15 <AutomatedTester> Agenda: https://www.w3.org/wiki/WebDriver/2020-07-BiDi
16:06:19 <JohnChen> present+
16:07:43 <AutomatedTester> topic: Follow-ups from previous meeting
16:07:48 <Gerry_Gao> Gerry_Gao has joined #webdriver
16:08:31 <AutomatedTester> foolip: The spec is not entirely empty any more, it does initial connection and parsing the body of the commands
16:08:44 <AutomatedTester> ... there are not commands that exist at the moment
16:08:55 <AutomatedTester> ... we need to add commands now
16:10:09 <AutomatedTester> jgraham: we've managed to get the surfacing of the ws to webdriver
16:10:26 <AutomatedTester> jgraham: and the rest of the meeting is more important items
16:10:35 <AutomatedTester> topic: Command/event organisation
16:10:43 <Gerry_Gao_> Gerry_Gao_ has joined #webdriver
16:10:50 <AutomatedTester> jgraham: I have opened an issue on this topic
16:11:04 <AutomatedTester> https://github.com/w3c/webdriver-bidi/issues/17
16:11:21 <AutomatedTester> ... what is the smallest amount of documentation do we need to do here
16:11:49 <AutomatedTester> ... people have been assumed that commands will by like CDP e.g. namespacing to things like Domains
16:12:12 <AutomatedTester> ... so my question is do we want to have that people turn on and off domains
16:12:39 <AutomatedTester> ... before people can use or stop using those items
16:13:12 <AutomatedTester> ... it feels like the CDP approach is designed off a devtools panel design
16:13:52 <bwalderman> q+
16:14:01 <foolip> q+
16:14:09 <simonstewart> q+
16:14:46 <AutomatedTester> bwalderman: CDP as it is organised today is definitely off a devtools panel
16:15:14 <AutomatedTester> ... because we have multiple browser contexts we need to have a mechanism that we do this
16:15:20 <jgraham> q+
16:15:26 <AutomatedTester> we have a 2d model. A context and domains
16:16:02 <AutomatedTester> I submitted a proposal yesterday about this
16:16:07 <AutomatedTester> q-
16:16:13 <jgraham> ack
16:16:21 <AutomatedTester> ack bwalderman
16:16:24 <jgraham> ack
16:16:25 <AutomatedTester> ack foolip
16:17:00 <AutomatedTester> foolip: do we really need to enable domains?
16:17:06 <foolip> ack
16:17:07 <AutomatedTester> bwalderman: yes, for collecting events
16:17:12 <AutomatedTester> q?
16:17:17 <AutomatedTester> ack simonstewart
16:17:20 <bwalderman> https://github.com/w3c/webdriver-bidi/pull/41
16:17:28 <foolip> So to clarify, one does not need to enable to domain in order to use a command in that domain
16:17:51 <diemol> diemol has joined #webdriver
16:17:55 <AutomatedTester> simonstewart: I think when we discussed this before, we want to minimise the amount of data that comes back as people will likely put the internet inbetween  their client and browser
16:18:26 <bwalderman> q+
16:18:36 <AutomatedTester> ... I think the global approach to context here is better
16:18:38 <AutomatedTester> ack jgraham
16:18:49 <AutomatedTester> jgraham: the global approach is needed for automation
16:19:06 <AutomatedTester> ... e.g. if a new context loads you will want to get events straight away
16:20:28 <AutomatedTester> ... [discusses how to get filtering]
16:20:32 <AutomatedTester> q?
16:20:36 <AutomatedTester> ack bwalderman
16:21:15 <AutomatedTester> bwalderman: simonstewart  mentioned that race conditions can happen, global events will needed to make sure that we can get everything
16:21:46 <AutomatedTester> ... cdp sometimes creates an empty page , sets listeners and then navigates.  We should support both cases
16:22:23 <jgraham> q?
16:22:32 <AutomatedTester> ... it will be good to specify that a domain be used on one context
16:22:34 <jgraham> q+
16:23:34 <AutomatedTester> jgraham: in summary: spec wise to organise this in domains and have events be both global and down to specific contexts
16:23:37 <foolip> q+
16:23:41 <jgraham> ack
16:23:43 <AutomatedTester> ack jgraham
16:23:59 <AutomatedTester> ack foolip
16:26:24 <mathiasbynens> TL;DR a way to enable a given list of events for a given list of targets. the lists could support wildcards of some sort
16:26:41 <jgraham> Organise events in domains. Events can be enabled singly (or in groups?). Global enabling or enabling for specific targets (browsing contexts etc.) are both to be supported
16:26:46 <AutomatedTester> topic: Target discovery and message routing
16:27:26 <AutomatedTester> bwalderman: Earlier this week I tried to enumerate the targets we would want to support
16:27:49 <AutomatedTester> ... I added to the proposal addressable objects. These are the top level targets
16:28:57 <foolip> q+
16:29:01 <AutomatedTester> ...Windows, service workers, shared workers are the context we need to start from
16:29:33 <AutomatedTester> ack foolip
16:29:50 <AutomatedTester> foolip: I think that covers the basis for a good start
16:29:51 <brrian> q+
16:30:05 <AutomatedTester> ... I wanted to ask questions about terminology here
16:30:06 <jgraham> q+
16:30:19 <bwalderman> q+
16:30:45 <AutomatedTester> foolip: can you just explain that?
16:30:59 <AutomatedTester> bwalderman: I attempted to use the same terminoligy from the html spec
16:31:36 <AutomatedTester> ...there is no "tab" in the html spec, it is a top level browser context
16:31:46 <AutomatedTester> ... and that can have nested items in there
16:32:16 <AutomatedTester> foolip: about a window then, what do we mean here?
16:32:32 <AutomatedTester> bwalderman: a window is the browsing context
16:32:37 <AutomatedTester> q?
16:32:45 <jgraham> I think we shouldn't use the word window here, the WebDriver/HTTP terminology is legacy
16:32:51 <AutomatedTester> ack brrian
16:33:04 <mathiasbynens> also Window vs. WindowProxy as foolip mentioned
16:33:29 <foolip> bwalderman: to be clear, I didn't mean to say your proposal is messy, but that the terminology around this is messy
16:33:39 <simonstewart> q+
16:33:52 <AutomatedTester> brrian: sometimes webdriver is driving things that arent a real window. What is the use case as a serviceworker as  top level target
16:34:48 <AutomatedTester> bwalderman: it was just because they are accessible
16:34:50 <AutomatedTester> q?
16:34:54 <foolip> interception a network request that a service worker makes seems like a straightforward use case for this
16:35:17 <AutomatedTester> ack jgraham
16:35:19 <foolip> s/interception/intercepting/
16:35:53 <AutomatedTester> jgraham: I don't think we should have a top level item that is a union of all addressable items
16:36:13 <JohnJansen> q+
16:36:15 <cb> q+
16:36:35 <AutomatedTester> ... there are cases where it makes sense to set messages for realm to get messages out of it
16:36:41 <AutomatedTester> q?
16:36:51 <bwalderman> q-
16:37:29 <AutomatedTester> ... we started based off that but I dont think  we need to over abstract it
16:38:10 <foolip> jgraham: +1 to that view/summary
16:38:20 <cb> q-
16:38:31 <simonstewart> +1 too
16:38:40 <AutomatedTester> ... I think we should try avoid using window where we can
16:38:43 <JohnJansen> q-
16:39:14 <AutomatedTester> ... historical reason window is very different and we may need to have an explainer about the difference here
16:39:17 <AutomatedTester> q?
16:39:24 <AutomatedTester> ack simonstewart
16:39:49 <AutomatedTester> simonstewart: We can tighten up the original spec
16:39:55 <jgraham> window is used in the http protocol so we can't remove it entirely
16:40:19 <AutomatedTester> ... are you do mean to do a tree of the items and how they interact
16:40:33 <cb> one example for using service workers in the context of WebDriver is e.g. testing https://squoosh.app/ where you don't always want to run the service worker to compress an image but emulate certain responses from it
16:41:29 <AutomatedTester> bwalderman: it makes sense to limit commands within targets e.g. window resize makes no sense on service workers
16:41:35 <foolip> cb: neat, would that be by intercepting a network request the service worker makes, or intercepting the request that will go to the service worker?
16:41:47 <drousso> q+
16:41:48 <AutomatedTester> ... but we need to have something that can be extensible
16:42:15 <foolip> q+
16:42:20 <AutomatedTester> simonstewart: did you think about sending errors when targets are sent something silly
16:42:42 <AutomatedTester> bwalderman: yes we can
16:42:51 <mathiasbynens> I guess Simon is arguing that we _could_ leave some things as implementation-defined. While certainly possible, it seems better to spec what we can
16:42:52 <cb> @foolip more intercepting request to/from the service worker and the app but I can see examples where you also want to intercept network request made by the service worker
16:42:59 <jgraham> We do need to because we need lifecycle events, and you need to know what kind of object it is
16:43:06 <AutomatedTester> simonstewart: do we need to enumerate the top level items
16:43:49 <JohnJansen>  @foolip, it looks like you are scribing what cb said, not asking him a question. :-)
16:44:01 <AutomatedTester> bwalderman: yes, we need to enumerate types of targets we need to support and the set of commands we need to support. We don't want to have a generic target type
16:44:05 <AutomatedTester> q?
16:44:15 <AutomatedTester> ack drousso
16:44:43 <foolip> JohnJansen: hmm, how do I avoid that? I thought since I'm not the scribe I can just chat :)
16:44:47 <AutomatedTester> drousso: I second simonstewart 's idea, we dont need to specify everthing straight away
16:45:41 <AutomatedTester> ... web inspector can break on some events. Some of these things can be in different targets that can change all the time or augmented in the future
16:45:44 <JohnJansen> avoid the colon.
16:45:59 <AutomatedTester> ... I think it would be better to send the command and error if it can't handle it
16:46:28 <simonstewart> q+
16:46:42 <AutomatedTester> ... there could cases where we would want a proietary item that we can't spec here but want to use
16:46:49 <AutomatedTester> ack foolip
16:47:06 <AutomatedTester> foolip: I think these are issues we can solve when we ahve more commands
16:47:35 <AutomatedTester> q?
16:47:46 <AutomatedTester> ack simonstewart
16:48:25 <AutomatedTester> simonstewart: I think it would be good to get a command that surfaces the targets
16:48:47 <simonstewart> A command that surfaces the domains that each Target can support
16:48:50 <AutomatedTester> foolip: yea, that way we can have feature detection
16:48:54 <jgraham> I think I strongly agree with the idea we should look at this in the context of actual features rather than in the abstract
16:49:03 <jgraham> q?
16:49:09 <JohnJansen> q=
16:49:12 <JohnJansen> q+
16:49:29 <AutomatedTester> ack JohnJansen
16:50:03 <AutomatedTester> JohnJansen: I was looking at previous meetings and the serviceworker use case is for PWAs
16:50:09 <AutomatedTester> q?
16:50:15 <AutomatedTester> topic: Protocol definition formalism
16:50:59 <brrian> JohnJansen: more details on the operations desired would be super helpful :)
16:51:03 <AutomatedTester> jgraham: one of the things blocking progress is deciding how to represent commands
16:51:05 <Mkk> Mkk has joined #webdriver
16:52:32 <AutomatedTester> ... it is clear that we want use JSON Schema on the wire and it's not super human readable.
16:52:51 <AutomatedTester> https://github.com/w3c/webdriver-bidi/issues/21
16:53:02 <AutomatedTester> ... foolip has suggested
16:53:07 <AutomatedTester> ... webidl
16:53:16 <AutomatedTester> ... and I have seen ccdl from IETF
16:53:31 <AutomatedTester> ... or maybe we can write interface definitions in typescript
16:53:56 <AutomatedTester> ... I know CDP uses some custom format which is good but very CDP centric
16:53:58 <foolip> What I suggested was something only vaguely inspired by Web IDL in that it has {} and ; -- https://github.com/w3c/webdriver-bidi/issues/21#issuecomment-639094745
16:54:21 <bwalderman> q+
16:54:26 <simonstewart> Kind of liking the idea of Not Inventing Things
16:54:37 <bwalderman> q-
16:54:48 <foolip> q+
16:55:01 <AutomatedTester> ack foolip
16:55:12 <bwalderman> q+
16:55:56 <AutomatedTester> foolip: it will be good to know what we need like types, etc
16:56:22 <AutomatedTester> jgraham:  make sure we can talk about it in the abstract
16:56:33 <AutomatedTester> ack bwalderman
16:56:53 <AutomatedTester> bwalderman: one question, will we take what we use the tool to generate spec prose?
16:57:24 <AutomatedTester> jgraham: I want to add in blocks in the spec and the abstract items are added and explained
16:58:00 <AutomatedTester> ... we dont want the granularity we had in the webdriver http spec
16:58:15 <AutomatedTester> bwalderman: ok, as long as we dont have weird build steps
16:59:52 <foolip> thanks for facilitating, AutomatedTester!
17:00:04 <jgraham> RRSAgent: make minutes
17:00:04 <RRSAgent> I have made the request to generate https://www.w3.org/2020/07/01-webdriver-minutes.html jgraham
17:00:15 <simonstewart> It was lovely to see everyone :)
17:00:44 <jgraham> RRSAgent: stop