15:58:32 <RRSAgent> RRSAgent has joined #webdriver
15:58:32 <RRSAgent> logging to https://www.w3.org/2020/09/02-webdriver-irc
15:59:31 <jgraham> Zakim: this is webdriver-bidi
16:00:10 <jgraham> q?
16:00:34 <mathiasbynens> The meeting has not started
16:01:20 <jgraham> Yeah, so I think the problem is that with AutomatedTester away no one can start the zoom call
16:01:47 <john_chen> john_chen has joined #webdriver
16:02:23 <jgraham> So unless something changes, I think we either need to defer e.g. until next week or pick a different videoconf
16:02:29 <mathiasbynens> I could create an impromptu Google Meet URL?
16:03:13 <gsnedders> that works?
16:03:25 <jgraham> https://mozilla.zoom.us/my/jgraham ?
16:03:31 <mathiasbynens> let's go with ^
16:04:06 <drousso> drousso has joined #webdriver
16:05:06 <mathiasbynens> present+
16:05:16 <jgraham> For anyone still waiting to join the meeting, we changed conference rooms since AutomatedTester is away
16:05:22 <jgraham> present+
16:05:53 <drousso> present+
16:06:08 <Shengfa> Shengfa has joined #webdriver
16:06:59 <Maksim_Sadym> Maksim_Sadym has joined #webdriver
16:07:13 <jgraham> Agenda: https://www.w3.org/wiki/WebDriver/2020-09-BiDi#Agenda
16:07:58 <john_chen> present+
16:09:16 <foolip> present+
16:09:20 <gsnedders> ScribeNick: foolip
16:09:30 <brrian> present+
16:10:01 <cb> present+
16:10:18 <foolip> jgraham: agenda is at https://www.w3.org/wiki/WebDriver/2020-09-BiDi#Agenda
16:10:44 <foolip> jgraham: first agenda item is follow-up from last meeting. logging module and more?
16:11:06 <jgraham> foolip: does discussion need to continue?
16:11:52 <foolip> foolip: https://github.com/w3c/webdriver-bidi/issues/45 was filed
16:12:13 <foolip> jgraham: we can have the discussion on GitHub, but a bit early to specific an actual feature yet
16:12:57 <foolip> foolip: let's do https://github.com/w3c/webdriver-bidi/issues/43 first
16:12:57 <jgraham> topic: specifying navigating a browsing context
16:14:10 <jgraham> foolip: Once we hae basic protocol, how do we navigate? Inspiration from CDP and WebDriver. These are very different. WebDriver has page load strategies that can be set to define the behavior, and it blocks.
16:14:25 <jgraham> foolip: Navigate and then return.
16:14:51 <jgraham> foolip: CDP model is request navigate and then events happen and client has to wait
16:15:02 <jgraham> q+
16:15:31 <cb> q+
16:15:46 <jgraham> foolip: Opinions? Vaiations are possible e.g. progess updates, which aren't quite like CDP
16:15:58 <gsnedders> ack jgraham
16:16:19 <foolip> jgraham: I think the point of this is to do something more like CDP in these cases, that the protocol should be lower level and not having blocking commands
16:16:30 <foolip> jgraham: I'd be against adding a long-running blocking command for navigation, or anything
16:16:56 <foolip> jgraham: not sure about the progress update model was, but my assumption is you send a navigate command and then start getting events for various points in the lifecycle
16:16:58 <foolip> q?
16:17:21 <foolip> jgraham: I think CDP has more events for network stuff, maybe it all falls out of performance timing
16:17:27 <foolip> ack cb
16:17:32 <foolip> cb: +1 to that
16:17:55 <foolip> cb: the reason we're looking at CDP is that it allows the browser to be introspected
16:18:21 <foolip> cb: which makes it really powerful. people will use a framework that abstracts complex logic like listening to certain events
16:18:41 <foolip> cb: someone with no understanding of the protocol would be able to use it through a framework
16:19:32 <brrian> q+
16:19:39 <foolip> ack brrian
16:19:40 <jgraham> foolip: Means that we have to define lots of events to make navigation work, but there's some chance to start with just e.g. DOMContentLoaded
16:19:55 <foolip> brrian: beyond sending a response once load is done/canceled, I don't think anyone else needs to go in
16:20:06 <foolip> brrian: that said, it can take a very long time for a navigation to be committed
16:20:18 <foolip> brrian: don't see a big difference between the time it will take
16:20:18 <Hexcles> Hexcles has joined #webdriver
16:20:34 <foolip> brrian: what we've done in the web inpector protocol is async commands, where responses can come out of order
16:21:16 <jgraham> foolip: is navigation committing a thing we want to block on?
16:21:25 <foolip> brrian: I see no reason to return early if you can't do anything with it
16:21:40 <jgraham> q+
16:21:57 <jgraham> foolip: How does this work in web inspector
16:22:07 <foolip> brrian: there's no timeout for the navigation
16:22:22 <foolip> brrian: not sure how to specify it, it can take a long time to navigate
16:22:33 <drousso> +1 to that ^
16:23:24 <foolip> drousso: in web inspector there's no navigate command, that's triggered by JS
16:23:38 <foolip> drousso: but while you're navigating, what is there for you to do in the page?
16:23:53 <foolip> q?
16:23:56 <foolip> ack jgraham
16:24:29 <foolip> jgraham: one thing that might be different from the underlying inspector protocol is that we're mulitplexing a bunch of browsing contexts for a single connection
16:24:48 <foolip> jgraham: so maybe you should be able to navigate one while you do other work in another
16:25:16 <foolip> jgraham: way I thought this would work is you navigate, and the response tell you only "yes that was a well-formed command, I can try to navigate based on that"
16:25:18 <drousso> q+
16:25:32 <foolip> jgraham: and later, you get some event, not with the command ID, but with the browsing context ID, say
16:25:39 <foolip> jgraham: that does have implications for client authors
16:25:54 <foolip> jgraham: there could later be an error, if the navigation couldn't actually occur
16:26:06 <foolip> jgraham: but in other ways it seems similar to the async command model
16:26:26 <foolip> jgraham: the difference I think is whether you can send no response at first and later send a response with the command ID
16:26:47 <gsnedders> q?
16:26:59 <foolip> jgraham: or if there should always be a response saying "that packet was valid" and later can't send another reponse for that
16:27:09 <gsnedders> q+
16:27:13 <foolip> drousso: that's is what I was describing as an async command
16:27:35 <foolip> drousso: but rather than sending an empty response, we can tie them together
16:28:02 <gsnedders> ack drousso
16:28:11 <jgraham> foolip: Still some choices to make here. Can take it to the issue
16:28:20 <jgraham> ack gsnedders
16:28:47 <foolip> gsnedders: want to point out a bunch of potential error cases, where the client fails to communicate with the browser, which might have crashed or is running on another machine
16:28:55 <brrian> Also, due to multiprocess and embedder navigation policy, WebKit can't synchronously tell if a navigation is valid or to be cancelled.
16:28:57 <foolip> gsnedders: so there are cases where even commiting the navigation can fail
16:29:13 <foolip> jgraham: we're 50% through our time
16:30:05 <jgraham> topic: cddl refactor
16:30:28 <foolip> issue is https://github.com/w3c/webdriver-bidi/pull/50
16:30:35 <foolip> jgraham: don't think there's loads to discuss
16:30:44 <foolip> jgraham: point of the PR is to fill out more of the basic infrastructure in the spec
16:31:10 <cb> q+
16:31:14 <foolip> jgraham: one of the things it does is change how we use CDDL. initially had a single CDDL fragment per command
16:31:31 <foolip> jgraham: in theory we could extract the schema for the spec, given the right tooling which doesn't exist
16:31:50 <foolip> jgraham: it defines remote end and local end schemas for validating messages
16:32:08 <foolip> jgraham: it's slightly awkward, using CDDL is a little bit of a compromise, but I think it's an improvement
16:32:35 <foolip> ack cb
16:32:58 <foolip> cb: to confirm, we'll have all the definitions in the spec and need to build tooling that extracts it into a single CDDL file?
16:33:03 <foolip> jgraham: yes, that's the idea
16:33:18 <mathiasbynens> topic: basic support for subscribing to events
16:33:22 <foolip> issue is https://github.com/w3c/webdriver-bidi/pull/51
16:33:30 <Hexcles> Hexcles has joined #webdriver
16:33:40 <foolip> jgraham: this is based on the previous PR
16:33:53 <foolip> jgraham: adds the basic mechanism for subscribing to a specific event stream
16:34:12 <foolip> jgraham: there are compromises which might be worth discussing
16:34:24 <foolip> jgraham: at the moment it's in a session module, which I'm not attached to
16:34:37 <foolip> jgraham: you can pass in module names and a list of browsing context IDs
16:34:44 <foolip> jgraham: I didn't deal with real-specific cases like service workers
16:35:11 <foolip> jgraham: at the moment, you can enable events globally, like "tell me when a new browsing context is created"
16:35:34 <foolip> jgraham: you can also apply it to a specific browsing context and its descendants, unless you unsubscribe on a given descendant
16:36:02 <foolip> jgraham: if you subscribe to logging, you get it for frames as well unless you opt out. that was an arbitrary choice. I think Brandon had advocated for that, but people may have opinions
16:36:05 <foolip> q+
16:36:08 <foolip> ack foolip
16:36:29 <foolip> foolip: is there a parameter in the command to avoid the descendents
16:36:51 <foolip> jgraham: not at the moment, would be more complicated, but possible
16:36:53 <foolip> q?
16:37:31 <foolip> jgraham: I don't have a strong sense of what the implementation tradeoffs are. My feeling is that this is probably sensible from the pov of automation clients, like if you want to see all the logging for a window.
16:37:40 <foolip> jgraham: that would all be part of the test
16:37:44 <mathiasbynens> seems sensible from an end-user perspective, but might be tricky with site isolation/OOPIFs
16:38:06 <mathiasbynens> (not pushing back per se, just saying it might be more challenging to implement)
16:38:34 <mathiasbynens> supporting descendents, that is ^
16:38:45 <gsnedders> yeah, OOPIFs seems like it makes it difficult, but only getting an event a new descendent is created is painful because then you can miss early events from it
16:38:46 <drousso> ^ +1
16:38:48 <jgraham> foolip: Are non-browsing context targets part of the the design?
16:39:02 <jgraham> jgraham: Not currently, but know it's needed
16:39:12 <foolip> mathiasbynens: out-of-process is hard, but that's an implementation concern
16:39:28 <foolip> mathiasbynens: you would like things to behave the same for in-process and out-of-process
16:39:35 <foolip> jgraham: yes, that worries me
16:40:24 <jgraham> foolip: Would hope that it's possible to have the same model for in/out of process, but it could be hard to actually make it work. Need implementation experience
16:40:34 <foolip> q?
16:41:57 <foolip> jgraham: another point is that for most test use cases you probably don't run into these problems
16:42:04 <foolip> foolip: can you clarify?
16:42:19 <foolip> jgraham: think it's common for tests to only care about a specific origin, that testing cross-origin is less common
16:42:53 <jgraham> foolip: Data point: we have a puppeteer bug with OOP iframes, so it is a thing that users run into
16:43:32 <foolip> jgraham: if we do something different here, can we do something better than the client could do?
16:43:50 <zcorpan_> zcorpan_ has joined #webdriver
16:43:52 <foolip> jgraham: is it better to punt it onto the client?
16:44:24 <jgraham> foolip: what we learnt from the bug is CDP pauses new targets until you have a chance to attach and register for events
16:44:45 <jgraham> foolip: Design is pretty weird, but could be a direction to explore
16:44:55 <foolip> q?
16:45:35 <foolip> gsnedders: on processes. given that we can be subscribed to multiple top-level browsing contexts, we can already be subscribed to multiple processes
16:46:12 <jgraham> foolip: easy to have a bug where you miss events from OOP iframes but in-process iframes work
16:46:23 <jgraham> topic: Resolving minor issues for basic transport
16:46:41 <foolip> first issue, https://github.com/w3c/webdriver-bidi/issues/47
16:47:22 <jgraham> foolip: number of connections. Noone wants to support multiple connections, but there are details about how to do that. If websocket closes, when is the state reset
16:47:33 <jgraham> q+
16:47:38 <foolip> ack jgraham
16:47:52 <foolip> jgraham: since Simon isn't here I will channel him for a moment
16:48:13 <foolip> jgraham: this only applies to "furthest remotes", not intermediary notes and such, they'll support multiple connections at a time
16:48:25 <foolip> jgraham: they could multiplex
16:48:45 <foolip> jgraham: but we still need to specify that for browsers there can only be one connection
16:49:39 <foolip> jgraham: scenario is if the WebDriver session is still open but the WebSocket connection was closed?
16:49:49 <foolip> jgraham: then spec should say you're able to connect?
16:50:00 <Shengfa> q+
16:50:33 <jgraham> foolip: easy to write a bug where the client thinks the connection is dropped but the server doesn't yet
16:50:43 <jgraham> ack Shengfa
16:50:43 <foolip> ack Shengfa
16:51:13 <foolip> Shengfa: What jgraham was saying about keeping the sessions state, if you first connect and subscribe. If you reconnect, are you still subscribed or do you have a clean state?
16:51:27 <foolip> Shengfa: If you want to keep the state, you have to record the events and send them back to the client.
16:51:49 <jgraham> q+
16:51:49 <foolip> Shengfa: On the other hand, if the WebDriver session closes, do we automatically close the WebSocket connection?
16:51:53 <foolip> ack jgraham
16:52:27 <foolip> jgraham: We've talked about event buffering before and it's very difficult. My fairly strong preference is we don't spend a lot of time worrying about it now, difficult to get it right.
16:52:45 <foolip> jgraham: I'm tempted to say that we don't buffer any events if you reconnect but you do retain the state
16:53:08 <foolip> jgraham: I think there's been conversations about allowing starting a session without the HTTP handshake, which I think will be possible, but there's conceptually still a connection
16:53:22 <foolip> jgraham: maybe in that case if the websocket connection drops the session ends, but we can think about that separately
16:54:19 <foolip> jgraham: But assuming an explicit WebDriver session, closing that should close the WebSocket connection
16:54:42 <foolip> foolip: If you start a session and then do nothing for a long time, won't the connection drop?
16:54:57 <foolip> jgraham: No, there is no connection, you've made a HTTP request and then there's no connection.
16:56:18 <foolip> topic: https://github.com/w3c/webdriver-bidi/issues/48
16:56:42 <foolip> jgraham: is it minimum maximum size?
16:56:46 <jgraham> foolip: Minimum size for the maximum message size
16:57:05 <jgraham> foolip: Matters because clients could not interoperate on this
16:57:32 <jgraham> foolip: Could be useful to look at existing limits. CDP/Chromium WebSocket might have 256Mb limit
16:57:34 <drousso> q+
16:57:42 <foolip> ack drousso
16:57:42 <jgraham> ack drousso
16:58:25 <foolip> drousso: along those lines, in web inspector we have commands that will send back the response content, which is content that came over the web, and you'll never encounter a 256 MB JS file
16:58:46 <mathiasbynens> challenge accepted
16:58:55 <jgraham> foolip: concern is that limi shouldn't be too small
16:59:03 <drousso> mathiasbynens: plzno 🤣
16:59:06 <foolip> drousso: these limits are likely limits that won't matter in practice
16:59:16 <jgraham> gsnedders: On mobile, limits might be more aggressive
16:59:17 <foolip> gsnedders: on a mobile device you might want a much more aggressive limit
16:59:30 <foolip> gsnedders: total amount of memory the device has sets a limit
16:59:48 <foolip> drousso: generally speaking, the limit only comes into play if we've designed the commands and events badly
17:00:11 <foolip> drousso: this will only come into play if we batch a whole lot of things together
17:00:35 <foolip> jgraham: think I agree with not ratholing on this too much
17:00:49 <foolip> jgraham: also think that things like print to PDF and screenshots can generate large messages
17:01:08 <foolip> jgraham: think I've seen multi-megabyte messages at least
17:01:26 <foolip> jgraham: a small number of commands that we have to base64-encode at the moment
17:01:33 <foolip> jgraham: maybe have some way to split that data up
17:02:31 <jgraham> I think some CDP things have a way to send back a handle you can use to get the data?
17:02:53 <jgraham> There's at least design options there
17:03:34 <foolip> Zakim: generate notes
17:03:42 <jgraham> RRSAgent: make minutes v2
17:03:42 <RRSAgent> I have made the request to generate https://www.w3.org/2020/09/02-webdriver-minutes.html jgraham
17:03:50 <jgraham> RRSAgent: make logs public
17:03:54 <foolip> jgraham: thanks :)
17:04:22 <cb> thanks for scribing @foolip @jgraham
17:04:43 <jgraham> RRSAgent: make minutes v2
17:04:43 <RRSAgent> I have made the request to generate https://www.w3.org/2020/09/02-webdriver-minutes.html jgraham
17:05:36 <jgraham> Meeting: WebDriver BiDi
17:05:48 <jgraham> RRSAgent: make minutes v2
17:05:48 <RRSAgent> I have made the request to generate https://www.w3.org/2020/09/02-webdriver-minutes.html jgraham
17:06:22 <jgraham> RRSAgent: bye
17:06:22 <RRSAgent> I see no action items