– DRAFT –
WebDriver Bidi - March 2023

rrsagent set logs world-visible

Use CDDL default value and ranges instead of pros

github: w3c/webdriver-bidi#368

whimboo: for the networking changes that are coming jgraham set some defaults in the cddl definition
… there was a question that came up about how do we have prose for this ?

jgraham: I haven't looked at how the lib (rust) behaves
… there are some oddities in the cddl definitions for defaults
… but I need to check into this a lot more
… and perhaps cbromann has more info

cb: When I wrote the npm package from cddl to AST to typescript I was able to do it
… but I saw you move to Rust and it might behave differently

jgraham: ok. I have also noticed that we don't have sufficient testing around the CDDL package

cb: I have been waiting for Saucelabs to transfer the package over to me so I will be able to contribute more on this

jgraham: great. I was just commenting that we haven't had testing of the cddl payloads as a priority and we should start doing that.

Consider moving WebDriver HTTP wpt tests to “webdriver/tests/http”

github: web-platform-tests/wpt#38768

whimboo: this is not for the spec but for where we store the wpt tests
… and since we started tests for webdriver-bidi it was added as a subfolder
… so do we want to move the "classic" tests to a new subdirectory

automatedtester: why not have a new highlevel dir?

whimboo: there are some tests that are shared between like window handles etc and not sure how easy that will be to share them

jgraham: I don't have opinion on moving it. One technical issue is that we have 150 char limit on path lengths which is enforced by wpt
… about the TLD it would require a lot of work to get things working
… and it's a issue with the wpt module setup so would not like to touch this if it purely for aesthetics.

whimboo: for the path lengths... I don't think that this is going to be an issue because of the way we are structuring these things. It's more "http" vs "classic"

gsnedders: I have an opinion

simonstewart: I think that v1 would be better than classic

jgraham: I am against v1
… and it becomes very confusing as we are working on it

simonstewart: I think that http would be better

whimboo: http can cause confusion and I think classic would be better

ACTION: Whimboo to move http based tests into /http

Pointer action subtype behaviour when subtype is unsupported

github: w3c/webdriver#1665

patrickangle: currently it is not clear in webdriver classic how we are supposed to handle "unsupported" on a platform. e.g. Touch on MacOS won't work
…  our current proposal is mouse is the default and it is aliased to the relevant item like pointer, mouse, touch

jgraham: I think that makes sense. It is a bug
… the spec can add new types in the future, we've done it before, so it make sense to tell you that the type is not supported
… in gecko we inject "fake events" that isTrusted
… but not at DOM level
… [explains how it works on Firefox for android]
… and in principle I am happy with that idea

gsnedders: There is more info in the issue tracker
… like on MacOS we can do it
… [describes complext touch inputs that can't be down with a mouse]

sadym: is it only about the subtype? or is about touch and click in a test?

patrickangle: we're mostly talking about the subtype here
… and what to do when one is not supported?

jgraham: Supporting touch on desktop is kinda allowed
… we can update the language in the spec but it is a bit of a question on what to do with your users
… if things still work great

gsnedders: the pointer tests in wpt they want to test everything separately
… so knowing if something is aliased is useful
… and if fallible that can be useful
… but sometimes the aliasing can make testing pointers harder

jgraham: the spec is wooly here... and it works pretty well for most cases
… I don't think that this potentially needs to be in a metric

gsnedders: There is talk around getting the mobile cases into the Interop report

gsnedders: for the normal users it defaulting to the alias of what the pointer is doing is "good enough"
… but isn't great for wpt

Add browsingContext parameter to script.addPreloadScript

github: w3c/webdriver-bidi#373

sadym: on this topic... we noticed the biggest difference between cdp and bidi there is no way to pass in the browsing context
… e.g. if you want to set MutationObserver on a specific page you cant
… so our suggestion is to add the browsingContext to the method

jgraham: I think this usecase was never discussed
… though it does feel like addPreloadScript will t hen exist for the rest of the life cycle of that context
… but I don't see an issue here

sadym: do we want context or contexts. The latter prevents round trips

jgraham: being able to supply more than one makes most sense

Extend browsingContext.ReadinessState with networkIdle and networkAlmostIdle

github: w3c/webdriver-bidi#374

sadym: we have 2 more values that are used heavily in puppeteer than what we are already have in the spec
… so we would like to add these 2 things. I know that jgraham has concerns about how t o spec this

ack

patrickangle: I share the same concern as jgraham
… if we can do this with on top of network interceptions

sadym: we can do it that there were X values in a time frame
… and if we can do it on the netwrok logging I think that we should be able to spec this out

patrickangle: I am now more concerned about putting this into webdriver. I feel that it would be better to be in the in client and they can explain it to users better
… I don't think this is good for each of the impl doing this heuristic

ack

jgraham: I think I agree with patrickangle here
… I am worried that people will depend on this heuristic and that won't be fully interop because the timing of the network requests could be different between each browser
… but if clients are already depending on this then I guess we're going to need to figure out how this works
… If we are going to spec this we are going to need to get more indepth details on how CDP is working
… if it is basically a heuristic should we say that we return when N requests are left in T seconds

ACTION: sadym to write down in depth how CDP works here so we can make a more informed decision

Should we serialize platform objects as JS objects with enumerable own properties included

github: w3c/webdriver-bidi#352

sadym: should we serialize platform objects like JS objects, with own props? etc
… and I created a PR for this.

jgraham: I think the reason it doesnt work like that atm
… platform objects implicitly get different way of serialising
… it would be useful to get feedback from clients on what they really want here
… we have had some theoretical goals here but it would be good to get real world info
… and we've tried to avoid creating a new type
… and another concern is "What does the extension story look like here?"
… if we move from platform object to normal are we going to break client code
… one thing we do that cdp doesn't do is "serialising the constructor"
… I can see there being a lot of value in sharingt he constructor back to the client for the platform objects
… and we can carry on in the issue tracker