Meeting minutes
RRSAgent: nolisten
<foolip> mathiasbynens will be here for the second hour
Network interception
<simonstewart> Is there a link to the issue?
jgraham: One of the common use cases for bidi from Selenium and we've seen it in puppeteer is the ability to see when a specific request happens and do a specific case
… such as basic auth
… or the othre request is network requests where we can say if X happens that we mock those network requests
… I think this part of the "value add" feature sets
… I've been looking around at this and CDP has the Fetch domain
… [describes how CDP does this case]
… looking at WebKit it looks very similar
… Gecko has a very model in webextensions
<foolip> https://github.com/w3c/webdriver-bidi/issues/66
Github topic: https://github.com/w3c/webdriver-bidi/issues/66
… so we have precendent in this area
<jgraham> a/slightly different model/slightly different model/
<jgraham> RRSAgent: make minutes v2
<drousso> lol oops i used the wrong command :P
foolip: is the model to both replace response without doing the response or can we edit and pass it back
… that's how I think CDP does this
jgraham: I think there is a getResponse type command that you get it and then can edit it
… both seem like meaningful use cases
cb: is the scope of this feature to capture all web resources?
jgraham: I believe that the scope should be to all resource fetches
… there is a question that I don't know the answer to which is how would service workers handle this
simonstewart: there are a lot of implementations for how intercepting of auth since there are cases like webauthn
… puppeteer doesn't seem to have a handle on this yet
… are we going to make it flexible enough
jgraham: yes, those are important cases
… I am not sure they should be part of this API. I think they have already added webdriver features and they are best placed to handle this
… I've just looked and they have a VirtualAuthenticator for testing
simonstewart: Ive seen that in the selenium code base
drousso: the reason we have added the support for things like this purely for webinspector, not for automation but can be used there
foolip: can you replace request headers as you see fit?
drousso: yes, and there are some pass throughs that means if people dont have send all the items
brwalder: re: service workers. In CDP this is set at the network layer and would not work for service workers as that's different
jgraham: that makes sense. I did have a question around filtering of this. How would we limit this to browsing context/realm?
<shengfa> There is also recent code merge in ChromeDriver for webauth(https://chromium-review.googlesource.com/c/chromium/src/+/2488183) with reference links in commit message.
foolip: a question for brwalder : Does this bypass the cache?
brwalder: Enabling the fetch domain disables the cache
simonstewart: that's not true you need to do it manually
drousso: webkit turns it off
foolip: so we need to be smart here when designing it
simonstewart: I would like to discuss this more indepth
… I imagine people have in their minds what puppeteer do in the fetch domain
… are we wanting to have a similar model for the future
… I don't know how webkit do this
drousso: I dont know CDP but will explain webkit
… webkit does something similar that it takes a pattern for an interception and at what stage
… this is only request or response currently
… the engine will notice and emit an event to the front end
… requestContinue - carry on as normal
… [describes 3 other events]
… All of this par tof the network domain and not a separate domain
jgraham: I don't think we should have a spralling mass of modukes
brwalder: that sounds more or less like CDP Fetch
… and has similar workflow
… and if you want the cache disabled you have to do it manually
… and the same for service workers
simonstewart: So my understanding is that there will be a command that takes a regex and then emits events and you can manipulate it as you see fit
… and when you get an authentication request you will intercept and insert credentials or we can deny it
jgraham: I agree
simonstewart: and one thing more that we implicitly disable the cache
drousso: both chrome and webkit disable the cache if requested
… but when we are going to override anything we make sure that automatically disable the cache instead
jgraham: I think we need to be clear in the spec and it seems webkit are have the correct cache-disabling behaviour, especially for automation
… I cant see a use case for the CDP way other thank creating flaky tests
<jgraham> RRSAgent: make logs public
<jgraham> RRSAgent: make minutes v2
Resolution: Create a command that takes a regex and then emits events and users can manipulate requests and responses based on the events sent. When an authentication request is intercepted we can insert credentials or deny them
github-bot: end topic
Shadow DOM
Github Topic: https://github.com/w3c/webdriver/issues/350
jimevans: With the rising use of web components the ability to interact with Shadow DOM is getting more important
… right now those components are opaque to webdriver
… there are some work arounds using executeScript
… and some XPATH libraries have been able to pierce Shadow DOM because CSS does not have the ability to pierce the shadowroot
… we need a way to "switch" or "select" into a shadow dom and test the elements in there
… I have a straw man proposals
… THere are some outstanding questions:
… 1) What do we do with closed roots
… 2) and how do we handle this. E.g. could we do element.getShadowRoot() and continue from there
<cb> https://github.com/w3c/webdriver/pull/1320/files
jgraham: I like the shape of the proposal
… and like going element and being able to pierce this makes sense
… and I think that the reason why this hasn't happened hasnt been fundamental opposition to this, purely time
AutomatedTester: I remember from TPAC last year that the DOM member from Apple said there was opposition to allowing Shadow Roots from being pierced and they said this is the main reason why CSS piercing was not allowed but Jim has told us that XPATH can get around this issue
foolip: if I remember on Monday jgraham said that Shadow Roots would not be interacted the same was as in bidi as http
jgraham: in answer to foolip the serialisation is more generic
… we would serialise it and it would just serialise that is has a shadowroot
… since we have generic concept of node and not a web element
<foolip> ok that makes sense, if we're talking about merely finding out that something is a shadow host
jgraham: It feels like the DOM are not understanding us here and perhaps we need to go speak to them
… since this is open to Devtools but not us
… and the next item is to I wonder if we can simplify the API to accept a now and reusing webelement.
foolip: Is the frustration that people can not pierce things or are we going to have to do it for every boundary
jimevans: the proposal is to minimize the cognitive load to keep it "similar" to find elements
… except the sematics would be that you are specifically looking in the shadow
… no thoughts have been given for chaining
… this is purely for http and agree that bidi should be different
AutomatedTester: I can't see the how the people trying to reuse findElement as they seem very different to me, could you elaborate it
jgraham: I think that the DOM hierarchy would be on our side so we will be fine
jgraham: ffor foolip: re: CSS piercing was seen as bad by other WG
… and for piercing we need to make sure that piercing the Shadow DOM needs to be explicit
… I think we should do the simple case first and see how it goes
<jgraham> RRSAgent: make minutes v2
cb: I have a counter proposal. It would be good to extend element.findElement(withShadow=true) and that would look inside the shadow
jimevans: I don't have a problem with that approach either
… we just need to something
… the tricky bit we need to think about is that we have a new error code
… if you want inside a shadowRoot and we cant find it its because of the shadow dom and not the DOM
drousso: regarding piercing, I dont think that we want "special paths" for automation
… or these special paths need to be infrequent
mathiasbynens: in puppeteer we allow people to allow people register querySelectors on their own
… and then people can do what they want from there
… we have one called `pierce` that pierces shadowROot
and one called `aria` for accessibility
… I think that playright does something similar
jgraham: so looking at the PR we had this discussion 2 years ago
… the backwards compatiblity issue is that if we add new parameters then we can have silent failures
<mathiasbynens> To clarify, in Puppeteer you opt-in to shadow DOM piercing not through some new parameter, but by adding a prefix to the selector string. This was decided because that way, we can make it work for our 10+ APIs that accept selector strings
jgraham: the new end points mean you will get an explicit error here
… and that is better for everyone
<mathiasbynens> Puppeteer's built-in pierce handler: https://github.com/puppeteer/puppeteer/pull/6509/files
Resolution: Write up spec prose based on jimevans proposal and the for future proposals in this area use the learning from other frameworks to see how we can improve
github-bot: end topic
BiDi roadmap
foolip: I would like to get a good idea of how far we can go for clients and implementors. What is the MVP/product that we want o enable so that we have a North Star to aim for
mathiasbynens: for puppeteer last year we met at Mozilla to get cross browser support
… puppeteer is great but it's built on CDP which isnt great
… and now we have playwright that's very different
… and playwright is shipping their own browsers
… which has a limitation that they can never get to Mobile.
… We see webdriver bidi as the missing piece for getting better support for multiple browsers and since each project has their limitations
… we hope to use webdirver bidi and if need to use the escape hatch
… in chromium we hope to have a prototype by the end of next year for a few commands and the spec
simonstewart: As far as selenium as concerned is to try increase the progress so that we can have a stable user API based on the use cases that we have discussed before
… and the ability to evolve APIs as needed
… and we dont want people's investments in selenium to be lost
jgraham: Mozilla buys into this vision strongly. We are interested in browser interop concerns
… and we see a lot of feedback from the MDN survey that cross browser testing is hard
… and we want to work people here and with clients to make sure this all works
… I am currently working on spec stuff
… and I think we're on track to adding logging
… and I will likely look at realms
… and this will give us the infrastructure to be able to add more meaningful commands in the future
… and I want to get to a stage where we can get more people working on the spec
… in terms of implementation. We see this as a priority. We are currently finishing off site isolation but then will move back to this work
… I can't state where we will be by this time next year
… and I hope will resource it as best we can
<foolip> where do we *need* to get to by this time next year?
shengfa: in terms of the roadmap... I would like to add that there should be some effort put into WPT
<foolip> +1 +1 +100 :)
shengfa: so that we can get some references into the pipeline early
… I am currently trying to add websockets to wpt
… and we need to be able have an async style of testing
… and we need to do commands and perhaps /status would be a good place to start
<shengfa> WIP: https://github.com/web-platform-tests/wpt/commit/61e6da80428d49f8e6efe779658596b6b38e53e4
jgraham: this is exciting that we are doing this straight away
… and if I can help with reviewing let me know
… and it would be good to see a RFC for this work
foolip: I would like to summarise and exaggerate what mathiasbynens and jgraham said
… for browsers having bidi and having tests that pass and using CDP as an escape to CDP
jgraham: that sounds like a good goal and the right direction of the work
… it's hard to predict how far we will get but its a good idea
… it would be good to move Selenium over first
… and prevent baking in CDP items to Selenium
simonstewart: if we could migrate Selenium first that would be awesome
foolip: just to check, this is for new APIS and not rewriting APIs
simonstewart: yea, this is for new APIs so that we don't ahve to rebuilding APIs with each Chromium release
AutomatedTester: are we moving things to Py3?
jgraham: Yes, WPT is by the end of the year
<foolip> Feb 1, 2021 is a date that's been thrown around.
jgraham: there might be something interesting question of 3.6 vs 3.7
… we have seen that people are moving across
shengfa: There is a plan to do py3 first vs py3 only
… there are plans for other scenarios
jgraham: yes, py3 by the end year for being run first and then a month later it will be py3 only. There will be an RFC "soon"
foolip: to our webkit friends, are there client libraries or support for other that are more important than bidi?
drousso: our focus is on standardized or will be standardized
… we are more interested in webdriver vs others
… we have a number of security concerns with automation that we can't guarantee with other clients
<jgraham> RRSAgent: make minutes v2
<cb> proposal: https://github.com/w3c/webdriver/pull/1552
Async Session Creation
Github Topic: https://github.com/w3c/webdriver/pull/1552
cb: So the idea is we async session creation job
… that has a defined set of events
… and it has the ability to check that session ID creation
… it has 3 endpoints
… the question is where does the session get the session ID back from
… if we allow a single event or all events
jgraham: I think this should be targeted at browser implementations as it seems really good for areas where are a lot of latency like grid or cloud providers
… I also am not sure that I can say that this is hard to justify the time to implement it there
… my suggest is specify in a different spec
… or make it optional for end nodes
simonstewart: I think you're right it's important for grid and I see what you mean by resourcing
… in a new spec is overkill
… and we can definitely mark this as a _may_
cb: The main thing for us to make sure that have enough time to get the machines ready at sauce and we don't need to have it like it is
jgraham: I think the main use case is definitely yours and I dont think browser vendors should stop you from speccing it
Resolution: Add this to webdriver http and mark the new command as a MAY
<foolip> I have to run, thanks everyone! (son is calling)
RRSAgent: bye
RRSAgent: make minutes v2