Meeting minutes
<jgraham> R
<jgraham> Zakim: This is Browser Tools and Testing
<jgraham> RRSAgent: make minutes
<jgraham> RRSAgent: make logs public
Follow-ups from previous meeting
foolip: The spec is not entirely empty any more, it does initial connection and parsing the body of the commands
… there are not commands that exist at the moment
… we need to add commands now
jgraham: we've managed to get the surfacing of the ws to webdriver
jgraham: and the rest of the meeting is more important items
Command/event organisation
jgraham: I have opened an issue on this topic
https://github.com/w3c/webdriver-bidi/issues/17
… what is the smallest amount of documentation do we need to do here
… people have been assumed that commands will by like CDP e.g. namespacing to things like Domains
… so my question is do we want to have that people turn on and off domains
… before people can use or stop using those items
… it feels like the CDP approach is designed off a devtools panel design
bwalderman: CDP as it is organised today is definitely off a devtools panel
… because we have multiple browser contexts we need to have a mechanism that we do this
we have a 2d model. A context and domains
I submitted a proposal yesterday about this
<jgraham> ack
<jgraham> ack
foolip: do we really need to enable domains?
<foolip> ack
bwalderman: yes, for collecting events
<bwalderman> https://github.com/w3c/webdriver-bidi/pull/41
<foolip> So to clarify, one does not need to enable to domain in order to use a command in that domain
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
… I think the global approach to context here is better
jgraham: the global approach is needed for automation
… e.g. if a new context loads you will want to get events straight away
… [discusses how to get filtering]
bwalderman: simonstewart mentioned that race conditions can happen, global events will needed to make sure that we can get everything
… cdp sometimes creates an empty page , sets listeners and then navigates. We should support both cases
… it will be good to specify that a domain be used on one context
jgraham: in summary: spec wise to organise this in domains and have events be both global and down to specific contexts
<jgraham> ack
<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
<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
Target discovery and message routing
bwalderman: Earlier this week I tried to enumerate the targets we would want to support
… I added to the proposal addressable objects. These are the top level targets
… Windows, service workers, shared workers are the context we need to start from
foolip: I think that covers the basis for a good start
… I wanted to ask questions about terminology here
foolip: can you just explain that?
bwalderman: I attempted to use the same terminoligy from the html spec
… there is no "tab" in the html spec, it is a top level browser context
… and that can have nested items in there
foolip: about a window then, what do we mean here?
bwalderman: a window is the browsing context
<jgraham> I think we shouldn't use the word window here, the WebDriver/HTTP terminology is legacy
<mathiasbynens> also Window vs. WindowProxy as foolip mentioned
<foolip> bwalderman: to be clear, I didn't mean to say your proposal is messy, but that the terminology around this is messy
brrian: sometimes webdriver is driving things that arent a real window. What is the use case as a serviceworker as top level target
bwalderman: it was just because they are accessible
<foolip> intercepting a network request that a service worker makes seems like a straightforward use case for this
jgraham: I don't think we should have a top level item that is a union of all addressable items
… there are cases where it makes sense to set messages for realm to get messages out of it
… we started based off that but I dont think we need to over abstract it
<foolip> jgraham: +1 to that view/summary
<simonstewart> +1 too
jgraham: I think we should try avoid using window where we can
… historical reason window is very different and we may need to have an explainer about the difference here
simonstewart: We can tighten up the original spec
<jgraham> window is used in the http protocol so we can't remove it entirely
simonstewart: are you do mean to do a tree of the items and how they interact
<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
bwalderman: it makes sense to limit commands within targets e.g. window resize makes no sense on service workers
<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?
bwalderman: but we need to have something that can be extensible
simonstewart: did you think about sending errors when targets are sent something silly
bwalderman: yes we can
<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
<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
<jgraham> We do need to because we need lifecycle events, and you need to know what kind of object it is
simonstewart: do we need to enumerate the top level items
<JohnJansen> @foolip, it looks like you are scribing what cb said, not asking him a question. :-)
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
<foolip> JohnJansen: hmm, how do I avoid that? I thought since I'm not the scribe I can just chat :)
drousso: I second simonstewart 's idea, we dont need to specify everthing straight away
… 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
<JohnJansen> avoid the colon.
drousso: I think it would be better to send the command and error if it can't handle it
… there could cases where we would want a proietary item that we can't spec here but want to use
foolip: I think these are issues we can solve when we ahve more commands
simonstewart: I think it would be good to get a command that surfaces the targets
<simonstewart> A command that surfaces the domains that each Target can support
foolip: yea, that way we can have feature detection
<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
JohnJansen: I was looking at previous meetings and the serviceworker use case is for PWAs
Protocol definition formalism
<brrian> JohnJansen: more details on the operations desired would be super helpful :)
jgraham: one of the things blocking progress is deciding how to represent commands
… it is clear that we want use JSON Schema on the wire and it's not super human readable.
https://github.com/w3c/webdriver-bidi/issues/21
… foolip has suggested
… webidl
… and I have seen ccdl from IETF
… or maybe we can write interface definitions in typescript
… I know CDP uses some custom format which is good but very CDP centric
<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
<simonstewart> Kind of liking the idea of Not Inventing Things
foolip: it will be good to know what we need like types, etc
jgraham: make sure we can talk about it in the abstract
bwalderman: one question, will we take what we use the tool to generate spec prose?
jgraham: I want to add in blocks in the spec and the abstract items are added and explained
… we dont want the granularity we had in the webdriver http spec
bwalderman: ok, as long as we dont have weird build steps
<foolip> thanks for facilitating, AutomatedTester!
<jgraham> RRSAgent: make minutes
<simonstewart> It was lovely to see everyone :)
<jgraham> RRSAgent: stop