15:59:34 <RRSAgent> RRSAgent has joined #webdriver
15:59:38 <RRSAgent> logging to https://www.w3.org/2023/07/12-webdriver-irc
16:00:13 <Zakim> Zakim has joined #webdriver
16:00:13 <jgraham_> Meeting: WebDriver-BiDi
16:00:21 <jgraham_> Agenda: https://www.w3.org/wiki/WebDriver/2023-07-BiDi#Agenda
16:01:26 <jgraham_> make logs public
16:01:29 <jgraham_> make minutes
16:01:33 <mathiasbynens> present+
16:01:39 <jgraham_> RRSAgent: make minutes
16:01:41 <RRSAgent> I have made the request to generate https://www.w3.org/2023/07/12-webdriver-minutes.html jgraham_
16:01:47 <jgraham_> RRSAgent: make logs public
16:02:01 <JimEvans> present+
16:02:07 <orkon> present+
16:02:08 <jrandolf> present+
16:02:09 <brwalder> present+
16:02:23 <jgraham> present+
16:02:32 <sasha> present+
16:02:37 <ChristianBromann> present+
16:03:43 <jgraham_> Chair: jgraham
16:03:54 <mathiasbynens> orkon volunteered to scribe
16:03:55 <simons> simons has joined #webdriver
16:04:09 <mathiasbynens> aka AlexRudenko or AlexRudenko1
16:04:09 <jgraham_> ScribeNick: orkon
16:04:18 <thiagowfx> q+
16:04:22 <thiagowfx> q-
16:04:24 <thiagowfx> present+
16:04:52 <simons> simons has left #webdriver
16:05:04 <lolaodelola> lolaodelola has joined #webdriver
16:05:05 <jrandolf> q+
16:05:08 <jrandolf> q-
16:05:14 <lolaodelola> present+
16:05:15 <simonstewart> simonstewart has joined #webdriver
16:05:24 <simonstewart> present+
16:05:30 <jgraham_> Topic: WebDriver BiDi roadmap
16:05:38 <jgraham_> https://docs.google.com/spreadsheets/d/1Cg3rifrBZClIitU3aFW_WDv64gY3ge8xPtN-HE1qzrY/edit#gid=0
16:06:13 <lightning00blade> lightning00blade has joined #webdriver
16:06:39 <orkon> jgraham_ (IRC): roadmap spreadsheet from the last meeting is sorted by priority
16:07:29 <orkon> jgraham_ (IRC): we don't necessarily need to work on this in the defined order but is anything missing? or misprioritzed?
16:07:43 <orkon> q+
16:07:49 <jgraham_> ack orkon
16:08:30 <jgraham_> orkon: I think a lot of things are in progress. Should we remove those from the list?
16:08:56 <mathiasbynens> q+
16:09:05 <jgraham_> ack mathiasbynens
16:09:14 <orkon> jgraham_ (IRC): we can cross out, perhaps add status column
16:09:54 <orkon> mathiasbynens (IRC): the spreadsheet was meant to be an extension of roadmap.md document so if we remove things, perhaps we should move it to roadmap.md
16:10:21 <mathiasbynens> to clarify, if we remove them _specifically because they're ongoing or finished_ https://github.com/w3c/webdriver-bidi/blob/master/roadmap.md
16:10:24 <orkon> jgraham_ (IRC): I agree, the doc is more use-case based but we should translate
16:11:07 <orkon> jgraham_ (IRC): let's refine P1 and P2 features into scenarios
16:11:17 <orkon> mathiasbynens (IRC): AlexRudenko will look into this
16:11:46 <jgraham_> Topic: Network request interception
16:12:00 <jgraham_> github: https://github.com/w3c/webdriver-bidi/pull/429
16:12:56 <orkon> jgraham_ (IRC): updated the PR, still missing the part of url pattern matching
16:14:15 <jgraham> simonstewart (IRC): You need to mute
16:15:59 <orkon> jgraham: there is URLPattern spec
16:16:25 <orkon> jgraham: the spec is complicated but if it gets a lot of adoption it might be good to use
16:16:40 <orkon> jgraham: webkit or firefox have no standards position on that yet
16:17:01 <orkon> jgraham: looked at existing pattern matching approaches but they are all slightly different
16:17:15 <orkon> jgraham: the simplest would be to match the full string
16:17:35 <mathiasbynens> q+
16:17:55 <jgraham_> ack mathiasbynens
16:18:03 <orkon> jgraham: we should also make sure we can migrate to a better format
16:18:23 <orkon> mathiasbynens (IRC): is it a problem that if we use full strings that URLs are not normalised? or is it a different issue?
16:18:35 <orkon> jgraham_ (IRC): maybe
16:19:09 <orkon> jgraham_ (IRC): the drawback is that you need to list all possible URLs
16:19:24 <orkon> mathiasbynens (IRC): URL spec defines how to normalise the URL
16:19:48 <orkon> mathiasbynens (IRC): we could start with a full string and then extend to the patterns (URLPattern)
16:20:50 <orkon> jgraham_ (IRC): we need to see if it works but we can discuss it in the spec
16:20:55 <orkon> q+
16:21:00 <jgraham_> ack orkon
16:21:31 <jgraham_> orkon: I also thought about URLPattern, but CDP doesn't use that and it's easier if it's compatible
16:22:07 <orkon> jgraham_ (IRC): we could re-use CDP syntax but it is still N+1 way of doing things
16:22:22 <orkon> jgraham_ (IRC): so I am concerned more about the platform effect
16:22:27 <orkon> q+
16:22:31 <jgraham_> ack orkon
16:23:02 <jgraham_> orkon: I think it's good to start with full URLs if possible, that would be a subset of what CDP supports
16:23:42 <jgraham_> Topic: add `type` for `Message` types
16:23:43 <orkon> jgraham_ (IRC): yeah, it makes sense, so we don't block on url pattern
16:23:51 <jgraham_> github: https://github.com/w3c/webdriver-bidi/pull/484
16:23:51 <jrandolf> q+
16:23:55 <jrandolf> https://github.com/w3c/webdriver-bidi/pull/484
16:23:56 <jgraham_> ack jrandolf
16:24:33 <orkon> jrandolf: while working on the chromium impl for webdriver bidi, we face problems to discriminate between message types in particular between top level types
16:24:55 <orkon> jrandolf: we wanted to implement a mechanism to discriminate them so we want to add a type attribute to messages
16:24:57 <jgraham_> q+
16:25:05 <orkon> jrandolf: or we could get rid of Extensible in the spec
16:25:27 <jrandolf> q-
16:25:34 <jgraham_> ack jgraham_
16:25:54 <JimEvans> q+
16:25:59 <orkon> jgraham_ (IRC): I am in favour of adding the type and it matches the pattern that we adopted for other places in the spec
16:26:40 <orkon> jgraham_ (IRC): we should be aware that it is a fundamental change so people should be aware but I do not think it will cause problems
16:26:46 <jrandolf> q+
16:27:21 <orkon> jgraham_ (IRC): based on previous discussions cddl has semantic to ignore extra fields so perhaps we dont need extensible but we perhaps need to explain in the spec what are the requirements for vendor extensions
16:27:35 <orkon> jgraham_ (IRC): for example in webdriver we used reserved key name patterns
16:28:26 <jgraham_> ack jrandolf
16:28:39 <orkon> jgraham_ (IRC): having some way to do vendor specific stuff is important. Whether it needs to be on the top level, idk but perhaps there are use cases for that. For example, logging through an intermediarz
16:28:39 <orkon> s/intermediarz/intermediary/
16:29:03 <orkon> Jim Evans: as a client author, I think adding the type property is no problem and seems natural
16:29:46 <orkon> Jim Evans: as far as extensible goes, as a client author, it is important to be able to handle that come across the wire that may not strictly, e.g., if the client receives smth from the remote end where the client has not caught up yet
16:30:14 <jgraham_> ack jrandolf
16:30:14 <orkon> Jim Evans: we need some mechanism to say that there will be other properties that you might or might not need to handle as a client
16:30:26 <jgraham_> ack JimEvans
16:31:03 <jgraham_> q+
16:31:07 <orkon> jrandolf: James you mentioned that Extensible can be used as a means of transporting implementation specific metadata. From looking from the users it was built to allow future keys
16:31:30 <orkon> jrandolf: I find it weird that we do it for the future compatibility
16:31:32 <orkon> jrandolf: to reserve the space to change the spec
16:32:00 <orkon> jrandolf: the way I see it if it is for metadata why not have the metadata field and get rid of extensiblity
16:32:02 <jgraham_> ack jgraham_
16:32:25 <orkon> jgraham_ (IRC): I don't really understand the point about the metadata specifically
16:33:30 <orkon> jgraham_ (IRC): there are a couple of kinds of extensibility: we want to be able to add stuff to the spec to allow existing client to not refuse the message. As long as the client data is there, they should process the message. If we want the behaviour to change, we need to make it explicit so that the clients process it with the new semantic
16:33:43 <jrandolf> q+
16:33:52 <orkon> jgraham_ (IRC): so it looks like cddl supports this explicitly.
16:34:13 <orkon> jgraham_ (IRC): the second kind is when the people want to add vendor-specific data and that is not necessarily metadata
16:34:28 <orkon> jgraham_ (IRC): new session is a clear example where there are browser specific options
16:34:55 <orkon> jgraham_ (IRC): so to be able to dump this stuff into the message seems fine
16:35:38 <orkon> jgraham_ (IRC): example from classic, if you talk to selenium grid or other components, and they might need to add some extra data that might be metadata but is it really? perhaps
16:36:08 <orkon> jgraham_ (IRC): I guess that stuff makes sense perhaps to add to metadata but then we have the same issue with the metadata field to avoid collision
16:36:16 <orkon> jgraham_ (IRC): and we end up with key namespaces
16:36:23 <jgraham_> ack jrandolf
16:36:28 <orkon> jgraham_ (IRC): it is where we ended up for classic
16:37:21 <orkon> jrandolf: I think it should be made clear that cddl does not define that more entries match or does not match the spec and it means that it is ambigious state.
16:38:18 <orkon> jrandolf: for sure having this extensible map is actually good if we want the client authors to understand that there will be extensions in the future. However, I don't see how the extensible trait guarantee any kind ... make anything easier? it is meant for documentation?
16:38:53 <orkon> jrandolf: you mentioned the namespacing but that was the point of metadata and we put this extra vendor information into this dedicated key
16:39:21 <orkon> jrandolf: in other rfcs usually a registry get created so that top level is not polluted
16:39:51 <orkon> jrandolf: metadata could be on anything and based on interpretation
16:40:27 <jrandolf> +1
16:40:30 <orkon> jgraham_ (IRC): I think there is clearly more to discuss. No objects to type key so we can go ahead. More discussion needed about extensible
16:40:53 <orkon> q+
16:40:54 <jgraham_> Topic: Update browsingContext.create to require the new context to active (in the foreground)
16:41:03 <jgraham_> github: https://github.com/w3c/webdriver-bidi/issues/475
16:41:09 <jgraham_> ack orkon
16:42:34 <jgraham_> orkon: The default is to create new contexts in the background, which creates problems due to throttling. We could either change the default, or we could require clients to activate the context when they do something meaingful with it. Opinions on what should happen? Gecko focuses the new one and then the original one. Background by default seems harder.
16:43:15 <orkon> jgraham_ (IRC): perhaps we can parametrize it in the command, activate or background
16:43:47 <orkon> jgraham_ (IRC): with the original webdriver the assumption was that the background window should always work which may or may not be possible
16:44:04 <orkon> jgraham_ (IRC): the original point was that you need to be able to do keyboard input
16:44:23 <orkon> jgraham_ (IRC): preferred would be to have a parameter
16:44:24 <jgraham_> q?
16:44:24 <orkon> q+
16:44:29 <jgraham_> ack orkon
16:45:38 <jgraham_> orkon: My preference is that we have a `background` parameter, so that contexts by default open in the foreground. This matches the user expectation in more cases. If we wanted background to be default, we could require users to send a second command to activate.
16:46:25 <jgraham_> orkon: Browsers don't really work with all tabs having focus like classic webdriver requires. Chrome headless implemented this, but it doesn't work for the headful browser.
16:47:08 <JimEvans> q+
16:47:22 <orkon> jgraham_ (IRC): we had a discussion that default values should be always false. So I think background parameter seems fine if we think that the foreground by default is the right thing
16:47:25 <jgraham_> ack JimEvans
16:48:15 <orkon> Jim Evans: it is worth noting that for implementations that I looked at when you say new tab that this tab is brought up in the foreground. So I think that should inform what the default should be here.
16:49:01 <jgraham_> q?
16:49:02 <orkon> jgraham_ (IRC): depending on how you open the tab e.g., via open a link in an new tab it might not be true. So having a parameter does make sense. Default for the foregound is fine
16:49:26 <jgraham_> Topic: Printing
16:49:36 <jgraham_> GitHub: https://github.com/w3c/webdriver-bidi/issues/473
16:50:31 <orkon> thiagowfx: I opened an issue that when the page dimensions are effectively zero (explicit setting or via margins). Currently the spec does not rule this out and there is a WPT test for that.
16:51:55 <jgraham_> q+
16:52:29 <orkon> thiagowfx: the expected result is to generate blank PDF with no content. This happens to work in Firefox but Chromium is not capable of producing empty content PDFs. Given that it is not a very useful scenario my proposal is to change the spec and WPT in some way: 1) rule out the case with empty dimensions with an error (InvalidArgument or smth) 2) let it work but allow implementations to fail on this case (UnsupportedOperation). what is the
16:52:29 <orkon> preference?
16:52:30 <jgraham_> ack jgraham_
16:53:10 <mathiasbynens> present-
16:53:45 <orkon> jgraham_ (IRC): in the spec at the moment you already allowed to send unsupported operation. But of course tests do not always assume. It is a bit tricky: we want the spec to have this clause and dont want to define the very specific implementation. Is it really only zero or some minimal size?
16:54:01 <orkon> jgraham_ (IRC): Henrik mentioned that there is some minimal size like 0.1 inch
16:54:21 <orkon> jgraham_ (IRC): if we define that, we can throw an invalid arg
16:54:41 <orkon> thiagowfx: are you advocating for not changing the spec?
16:55:05 <orkon> jgraham_ (IRC): we should change the spec for literal zero? the only question if the limit should be literal zero
16:55:37 <orkon> thiagowfx: the threshold will probably be 1 x 1 point
16:55:47 <orkon> jgraham_ (IRC): we should get that to the spec then
16:56:05 <jrandolf> q+
16:56:07 <thiagowfx> present-
16:56:18 <jgraham_> github: https://github.com/w3c/webdriver-bidi/pull/481
16:56:18 <jgraham_> ack jrandolf
16:57:41 <orkon> jrandolf: how do we feel about changing the names of properties to be more semantic? we took from WebDriver and it was built over time so it perhaps makes sense to rename some things, for certain params, like what does page mean? it stands for page dimensions
16:58:46 <orkon> jgraham_ (IRC): dimensions probably is a slight improvement, pages vs pageRanges perhaps not so much. given that the clients can expose it in whatever way, I am not sure it makes sense to add breaking changes
16:58:49 <jrandolf> Yes
16:59:00 <orkon> jgraham_ (IRC): another change was to require ranges to not require string parsing
16:59:23 <orkon> jgraham_ (IRC): I think it is a more interesting proposal as it removes some string parsing from strings
16:59:38 <orkon> jgraham_ (IRC): we didn't do it differently because it works like in the print dialog
16:59:45 <orkon> jgraham_ (IRC): I would be more inclined to change that
17:00:00 <orkon> jgraham_ (IRC): but I am slightly nervous about slight changes that do not add too much value
17:00:46 <orkon> simonstewart (IRC): I think we payloads will be compatible with classic we should keep the names. If BiDi part is unique, we should do whatever we want
17:00:58 <orkon> jrandolf: I guess then we dont do it
17:01:27 <orkon> present-
17:01:37 <jgraham_> RRSAgent: make minutes
17:01:38 <RRSAgent> I have made the request to generate https://www.w3.org/2023/07/12-webdriver-minutes.html jgraham_
17:02:13 <jgraham_> Zakim, bye
17:02:13 <Zakim> Zakim has left #webdriver
17:02:13 <Zakim> leaving.  As of this point the attendees have been mathiasbynens, JimEvans, orkon, jrandolf, brwalder, jgraham, sasha, ChristianBromann, thiagowfx, lolaodelola, simonstewart
17:02:13 <jgraham_> RRSAgent: bye
17:02:13 <RRSAgent> I see no action items