Meeting minutes
<jgraham_> make logs public
<jgraham_> make minutes
<jgraham_> RRSAgent: make minutes
<jgraham_> RRSAgent: make logs public
<mathiasbynens> orkon volunteered to scribe
<mathiasbynens> aka AlexRudenko or AlexRudenko1
WebDriver BiDi roadmap
<jgraham_> https://
jgraham_ (IRC): roadmap spreadsheet from the last meeting is sorted by priority
jgraham_ (IRC): we don't necessarily need to work on this in the defined order but is anything missing? or misprioritzed?
<jgraham_> orkon: I think a lot of things are in progress. Should we remove those from the list?
jgraham_ (IRC): we can cross out, perhaps add status column
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
<mathiasbynens> to clarify, if we remove them _specifically because they're ongoing or finished_ https://
jgraham_ (IRC): I agree, the doc is more use-case based but we should translate
jgraham_ (IRC): let's refine P1 and P2 features into scenarios
mathiasbynens (IRC): AlexRudenko will look into this
Network request interception
<jgraham_> github: w3c/
jgraham_ (IRC): updated the PR, still missing the part of url pattern matching
<jgraham> simonstewart (IRC): You need to mute
jgraham: there is URLPattern spec
jgraham: the spec is complicated but if it gets a lot of adoption it might be good to use
jgraham: webkit or firefox have no standards position on that yet
jgraham: looked at existing pattern matching approaches but they are all slightly different
jgraham: the simplest would be to match the full string
jgraham: we should also make sure we can migrate to a better format
mathiasbynens (IRC): is it a problem that if we use full strings that URLs are not normalised? or is it a different issue?
jgraham_ (IRC): maybe
jgraham_ (IRC): the drawback is that you need to list all possible URLs
mathiasbynens (IRC): URL spec defines how to normalise the URL
mathiasbynens (IRC): we could start with a full string and then extend to the patterns (URLPattern)
jgraham_ (IRC): we need to see if it works but we can discuss it in the spec
<jgraham_> orkon: I also thought about URLPattern, but CDP doesn't use that and it's easier if it's compatible
jgraham_ (IRC): we could re-use CDP syntax but it is still N+1 way of doing things
jgraham_ (IRC): so I am concerned more about the platform effect
<jgraham_> orkon: I think it's good to start with full URLs if possible, that would be a subset of what CDP supports
add `type` for `Message` types
jgraham_ (IRC): yeah, it makes sense, so we don't block on url pattern
<jgraham_> github: w3c/
<jrandolf> w3c/
jrandolf: while working on the chromium impl for webdriver bidi, we face problems to discriminate between message types in particular between top level types
jrandolf: we wanted to implement a mechanism to discriminate them so we want to add a type attribute to messages
jrandolf: or we could get rid of Extensible in the spec
jgraham_ (IRC): I am in favour of adding the type and it matches the pattern that we adopted for other places in the spec
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
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
jgraham_ (IRC): for example in webdriver we used reserved key name patterns
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 intermediary
Jim Evans: as a client author, I think adding the type property is no problem and seems natural
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
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
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
jrandolf: I find it weird that we do it for the future compatibility
jrandolf: to reserve the space to change the spec
jrandolf: the way I see it if it is for metadata why not have the metadata field and get rid of extensiblity
jgraham_ (IRC): I don't really understand the point about the metadata specifically
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
jgraham_ (IRC): so it looks like cddl supports this explicitly.
jgraham_ (IRC): the second kind is when the people want to add vendor-specific data and that is not necessarily metadata
jgraham_ (IRC): new session is a clear example where there are browser specific options
jgraham_ (IRC): so to be able to dump this stuff into the message seems fine
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
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
jgraham_ (IRC): and we end up with key namespaces
jgraham_ (IRC): it is where we ended up for classic
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.
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?
jrandolf: you mentioned the namespacing but that was the point of metadata and we put this extra vendor information into this dedicated key
jrandolf: in other rfcs usually a registry get created so that top level is not polluted
jrandolf: metadata could be on anything and based on interpretation
<jrandolf> +1
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
Update browsingContext.create to require the new context to active (in the foreground)
<jgraham_> github: w3c/
<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.
jgraham_ (IRC): perhaps we can parametrize it in the command, activate or background
jgraham_ (IRC): with the original webdriver the assumption was that the background window should always work which may or may not be possible
jgraham_ (IRC): the original point was that you need to be able to do keyboard input
jgraham_ (IRC): preferred would be to have a parameter
<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.
<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.
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
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.
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
Printing
<jgraham_> GitHub: w3c/
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.
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
preference?
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?
jgraham_ (IRC): Henrik mentioned that there is some minimal size like 0.1 inch
jgraham_ (IRC): if we define that, we can throw an invalid arg
thiagowfx: are you advocating for not changing the spec?
jgraham_ (IRC): we should change the spec for literal zero? the only question if the limit should be literal zero
thiagowfx: the threshold will probably be 1 x 1 point
jgraham_ (IRC): we should get that to the spec then
<jgraham_> github: w3c/
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
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
<jrandolf> Yes
jgraham_ (IRC): another change was to require ranges to not require string parsing
jgraham_ (IRC): I think it is a more interesting proposal as it removes some string parsing from strings
jgraham_ (IRC): we didn't do it differently because it works like in the print dialog
jgraham_ (IRC): I would be more inclined to change that
jgraham_ (IRC): but I am slightly nervous about slight changes that do not add too much value
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
jrandolf: I guess then we dont do it
<jgraham_> RRSAgent: make minutes