17:04:25 <RRSAgent> RRSAgent has joined #webdriver
17:04:30 <RRSAgent> logging to https://www.w3.org/2025/01/08-webdriver-irc
17:04:32 <Zakim> Zakim has joined #webdriver
17:04:33 <jimevans> present+
17:04:36 <jugglinmike> jugglinmike has joined #webdriver
17:04:37 <tidoust> scribe: tidoust
17:04:38 <jgraham> present+
17:04:54 <jugglinmike> present+ jugglinmike
17:05:06 <jgraham> Meeting: WebDriver BiDi
17:05:13 <lauromoura> present+
17:05:34 <jgraham> Agenda: https://www.w3.org/wiki/WebDriver/2025-01-BiDi
17:05:38 <benchatt5> benchatt5 has joined #webdriver
17:05:42 <jgraham> Chair: tidoust
17:05:45 <sasha> present+
17:05:51 <tidoust> present+ Francois
17:05:54 <benchatt5> present+
17:05:55 <jgraham> RRSAgent, make logs public
17:05:56 <whimboo> present+
17:05:57 <jdescottes> present+
17:05:57 <jugglinmike> present+ jugglinmike
17:06:00 <tidoust> Topic: Request for a "navigationCommited" event
17:06:01 <jgraham> RRSAgent: make minutes
17:06:02 <RRSAgent> I have made the request to generate https://www.w3.org/2025/01/08-webdriver-minutes.html jgraham
17:06:36 <tidoust> henrik: Put on the agenda because that is a requirement from Playwright.
17:06:53 <tidoust> ... Opposite of navigation started event that we currently have.
17:06:59 <simons> simons has joined #webdriver
17:07:03 <simons> present+
17:07:03 <spectranaut_> spectranaut_ has joined #webdriver
17:07:18 <tidoust> ... This would indicate that a navigation takes place.
17:07:29 <jamesn> jamesn has joined #webdriver
17:07:37 <jgraham> q+
17:07:39 <sadym> q+
17:07:50 <tidoust> ack jgraham
17:07:59 <tidoust> ack sadym
17:08:03 <jgraham> q+
17:08:27 <tidoust> sadym: It does make sense for us. The only question is where to put it in the specifications. It seems Alex has an idea to put it in the HTML spec.
17:08:34 <whimboo> so it is actualy the opposite of `navigation aborted` event
17:08:43 <tidoust> ... We do need it as well, we're going to implement.
17:09:07 <whimboo> q?
17:09:09 <tidoust> ack jgraham
17:09:49 <sadym> q+
17:09:56 <tidoust> jgraham: Question was when is the event emitted. It feels it needs someone who understands the invariant of when that event is emitted.
17:10:10 <tidoust> ... Reflect on how easy or hard it is to implement.
17:10:21 <tidoust> ack sadym
17:10:51 <jgraham> q+
17:11:08 <tidoust> sadym: It does make sense for us to emit that event when the document changes. When we see that the navigation is "committed". After that event, the navigation cannot be failed anymore. It can only be aborted.
17:11:14 <tidoust> ack jgraham
17:11:36 <tidoust> jgraham: Is somebody from Google able to make a PR for this, then?
17:11:40 <tidoust> sadym: Yes.
17:12:47 <jgraham> github: https://github.com/w3c/webdriver-bidi/issues/788
17:13:13 <tidoust> Topic: Support user context configuration
17:13:16 <jgraham> github: https://github.com/w3c/webdriver-bidi/issues/775
17:14:19 <tidoust> whimboo: New feature. What is requested here is to support a configuration context which gets automatically applied to any context that gets opened to any command.
17:14:30 <jgraham> q+
17:14:31 <tidoust> ... This is for commands but I think the same is also requested for events.
17:15:06 <tidoust> ... This is used by Playwright. Not sure about Puppeteer. Alex made a first step for events at least to be able to subscribe and unsubscribe automatically.
17:15:08 <sadym> q+
17:15:13 <tidoust> ... We'd want that from our side as well.
17:15:47 <tidoust> ... I have put a full list of options that Playwright that currently supports. I'm not saying that we should support all of them right away. Step by step, we can fill in new options.
17:15:58 <tidoust> ack jgraham
17:16:47 <tidoust> jgraham: You subscribe to events but instead of parsing the list of contexts, you would pass a specific list of user contexts. Same as what we have for viewports.
17:17:17 <tidoust> ... The way that works in CDP is I guess different but I think we'd want to avoid that.
17:17:36 <tidoust> ... It's not the most efficient protocol but that's the way it naturally integrates with what we have.
17:18:03 <whimboo> q+
17:18:33 <tidoust> ... We may want to consider another approach later on. There shouldn't be something specific to user context here.
17:18:50 <tidoust> ack sadym
17:19:14 <jgraham> s/viewports/contexts (traversables)/
17:19:22 <tidoust> sadym: I'm looking at the list of events used. I see some that we will not be able to set for user contexts because they are capabilities.
17:19:38 <tidoust> whimboo: I think we have a different issue for these, so we can ignore them for now.
17:20:00 <tidoust> ack whimboo
17:20:21 <jgraham> q+
17:20:39 <tidoust> whimboo: To follow up on James comment, what I remember is that they want to create a user context, configure it automatically, and the first tab that gets opened, gets the config.
17:21:07 <tidoust> ... With the viewport, it would mean the page already needs to be rendered.
17:21:14 <tidoust> ack jgraham
17:21:54 <whimboo> q+
17:22:01 <tidoust> jgraham: You can create a user context without creating any tab in that user context. The very first tab that the browser creates on startup is a bit of a specific case, but you can then do what you need afterwards.
17:22:02 <whimboo> q-
17:22:11 <tidoust> ... From that point of view, I don't think there's a problem.
17:22:15 <whimboo> q+
17:22:26 <tidoust> ack whimboo
17:22:51 <jgraham> q+
17:23:09 <tidoust> whimboo: About round-trips, If we have 50 settings, sending 50 commands take longer than sending them once.
17:23:23 <tidoust> ack jgraham
17:23:38 <tidoust> jgraham: The round trips here are not a major issue here.
17:23:55 <tidoust> ... It's not like they have to be serialized, you can send them as fast as possible.
17:24:27 <tidoust> ... It feels like a case where we could special case. Or we could not do that.
17:24:41 <tidoust> ... For CDP, I think this stuff is already multi-commands.
17:25:22 <tidoust> ... They block the user context, set the settings, then unblock. We would do slightly better. Not a perfect approach, but probably not that bad.
17:25:39 <sadym> correct
17:25:42 <tidoust> ... Once per user context rather than one per browsing context.
17:26:59 <tidoust> jgraham: First step is probably to land the events changes. Preloadscript is another one that we may want to do. And then look at other parameters, like viewport emulation and so on.
17:27:30 <tidoust> Topic: Support getting response body for network responses
17:27:35 <jgraham> github: https://github.com/w3c/webdriver-bidi/issues/747
17:28:28 <tidoust> jgraham: Use case is that people want to be able to initially read and then read and write the body of HTTP responses.
17:28:47 <tidoust> ... The difficulty is that these bodies may be rather large, so we can't send them fully over the wire.
17:29:17 <tidoust> ... We talked before about getting something like streaming, with some method to pull more data until it's complete.
17:29:39 <tidoust> ... The streaming approach seems necessary in at least some cases.
17:30:06 <tidoust> ... The request interception is already in place, but this thing is still missing. My understanding is that this has become the remaining "blocker".
17:30:22 <tidoust> ... Other thoughts on what the design should be here? Plans to work on this?
17:30:40 <jdescottes> q+
17:30:46 <tidoust> ... We'll eventually end up doing it, but it anybody else is looking into it, that would be better.
17:30:52 <sadym> q+
17:30:57 <tidoust> ack jdescottes
17:31:17 <tidoust> jdescottes: Question for Maksym. Any API in Puppeteer that exposes response bodies as a stream?
17:31:50 <tidoust> sadym: I had the impression that responseBuffer would return chunks, but it probably returns the whole thing at once.
17:32:05 <tidoust> ack sadym
17:32:37 <tidoust> sadym: I'm not sure if Alex is going to work on it soon or not, so cannot give you an estimate.
17:32:47 <jgraham> Maybe https://chromedevtools.github.io/devtools-protocol/tot/Network/#method-getResponseBodyForInterception allows getting the body as a string for intercepted requests
17:33:03 <sadym> https://chromedevtools.github.io/devtools-protocol/tot/Network/#method-getResponseBody
17:34:36 <tidoust> jgraham: It does look like CDP has both full body and chunk streaming capabilities, through getResponseBody and getResponseBodyForInterception
17:35:09 <tidoust> sadym: The only way it works is no chunk, but streams and base64 encoded streams.
17:35:45 <tidoust> jgraham: That suggests some possibility that we could start by returning the whole body as a string, which would certainly help us ship something faster.
17:36:10 <tidoust> ... It feels a good first step, but also scary if the body is a 2GB piece of data.
17:38:31 <tidoust> sadym: Currently, our implementation only provides a full body, even though the API offers an apparent stream. It may lead to a false "safe" feeling for the user where they feel they get a chunk of the data whereas we sent the entire thing under the hoods.
17:38:40 <tidoust> ... It may be better to stick to strings initially.
17:38:47 <tidoust> ... and thus the whole body.
17:39:28 <tidoust> jgraham: It seems there's some consensus to start with an API that gives you the full body.
17:39:55 <jimevans> q+
17:40:02 <tidoust> ... A possible complication compared with fetch is that chunks may need to be split across messages.
17:40:10 <tidoust> ack jimevans
17:40:35 <jdescottes> jdescottes has joined #webdriver
17:40:49 <tidoust> jimevans: Are we talking about a base64 encoded version of the body string? I worry about things such as people intercepting an image or any binary data.
17:42:02 <tidoust> jgraham: We need to support both. If it's a thing with a text content-type, we should return a string. If not, I'm not sure about the details but we need to support both use cases (base64 encoding and binary), and there's a pattern on how to do that.
17:43:01 <jgraham> RRSAgent: make minutes
17:43:03 <RRSAgent> I have made the request to generate https://www.w3.org/2025/01/08-webdriver-minutes.html jgraham
17:43:17 <jgraham> zakim, bye
17:43:17 <Zakim> leaving.  As of this point the attendees have been jimevans, jgraham, jugglinmike, lauromoura, sasha, Francois, benchatt, whimboo, jdescottes, simons
17:43:17 <Zakim> Zakim has left #webdriver
17:43:28 <sasha> sasha has left #webdriver
17:43:49 <jgraham> RRSAgent, bye
17:43:49 <RRSAgent> I see no action items