Meeting minutes
TPAC
Automatedtester: I have made sure that we have session space during TPAC on the Thursday and Friday. I can't be there unfortunately
jgraham: I think that we need to work out who is going to be there in person.
… we should probably set the agenda ahead of time
orkon: I will be there in person with Maksim and a couple other googlers.
Jim Evans: I will be there as a remote attendee
<jgraham> RRSAgent: make logs
<jgraham> RRSAgent: make minutes
ACTION: David - Make sure agenda is ready ahead of time and organsie the remote participation links
Network request interception update
github: w3c/
jgraham: this is mostly an update. I think the initial PR of this is ready to land
… we know the URL matching is not 100% done yet but it's heading in the right direction
… my recommendation is we land the current PR and then any issues get followed up in a future PR
Jim Evans: I am happy with this process so we get as much landed now and future URL matching in a future PR
orkon: on our side Diego is working on this but he is OOO this week. We were hoping to do some prototyping but it is looking good and we can get it landed sooner
jgraham: regarding the network response bodies I think that would be a good topic for TPAC. I didn't think it was a priority at the beginning but we can definitely follow up
jdescottes: Diego looked at this before going on PTO and he seemed happy with getting this landed as is
<orkon> Thiago -> Thiago
Add browsingContext parameter to script.addPreloadScript
github: w3c/
orkon: we are working on doing preload script. We are doing an implementation in this puppeteer. When working on this we found we couldn't implement this without the browsing context
jgraham: I think that should be pretty straight forward to specify. I would also like to understand the use case better
orkon: the use case is to support the puppeteer API. It allows people to have some isolation for preload scripts
whimboo: just to be sure if you load a page you might not know the browsing context? if the page is opened via window.open you would have to reload the page to get preload scripts into it?
orkon: Yes that is correct. This is mostly for iframes. We just wanted to check people's opinions and are happy to add a use case for this
jgraham: I assume you want preload scripts to work after navigation?
orkon: yes
jgraham: do you want this to work after document.open?
orkon: that shouldn't affect things here
jgraham: ok that's the answer I was hoping for
How would we approach file upload/filling out the file inputs?
<whimboo> https://
orkon: for puppeteer we have 2 requirements. 1: we should intercept the dialog. 2. we should be able to handle the file name
jgraham: setting the file path directly is what webdriver classic does already so we need to make sure that still works as is
orkon: we show the event in puppeteer which is then allows people to set the path on the element referenced in the event
jgraham: I assume this happens after an input action
jgraham: I don't see an issue here but I am not sure if this blocking in the UI
simonstewart (IRC): one of the things that people don't always like setting the file input
… but they still want to have a way to upload and we don't always have an ideal solution for our users
jrandolf: regarding drag and drop. We could implement drag info into the browser. but that's more of a drag and drop issue
simonstewart (IRC): drag and drop is a huge can of worms if we can avoid that. I think making sure we can handle the upload via a JS driven element is really important and we should make sure that we have that case covered
Jim Evans: THere is a little prior art here for when a user prompt is raised in the spec
… so perhaps we can do a very similar process can be done for file inputs
Support for cookie handling
github: w3c/
jgraham: This is something that we need to make progress on this. It is a high priority on the roadmap
… this is the biggest missing piece so far
… I think because in the previous webdriver it causes issues for our users
… and we need to make sure that we have it work well in all browsers
… There is a draft PR up
… could everyone start reading the draft PR so we can have a much longer discussion at TPAC
Allow creating new browsing profiles/contexts
github: w3c/
orkon: THis is something that has come up as a need for puppeteer. We would like to work on this for our users
… we also know that it is not fully compatible across browsers but I wonder if there are ideas about how we can get started with this
jgraham: I think the way to make progress here is enumerate the properties that we depend on in puppeteer
… it's not very clear to me are these private browsing "areas" or is it purely separate storage
… are they going to be named? is the name accessible? It's currently hard to know what properties are needed. E.g. In firefox is it private browsing or containers?
… I think that we should have an action to collect those things so we can work with other browsers to make sure that we know how this all maps
ACTION: Orkon - Collect these properties needed and put it in the issue with use cases of how people would use it
orkon: I will go collect these up
History navigation events
github: w3c/
jgraham: the question here is how do we want to expose history navigation in the API
… at the moment we have specific events
… for history and for fragments
… we don't have any events for the old history or the new history API in the browser. The latter is only in chromium
… so how should we expose this to an API? Should we have 1 event or map to a DOM event?
orkon: in CDP we don't distinguish between fragments and history
… we only have 1 type of event that people can listen to
… I don't think we have a usecase for more detailed events than that
automatedtester: jgraham do you want to see what CDP is doing and see if that is sufficient?
jgraham: yea maybe, I can see some cases where we want different types of events
… and puppeteer could always take the different events and map it to a single API
… I think we should make sure that we design it forward looking as much as possible
simonstewart (IRC): speaking with my selenium hat on I think having a single event type is much easier DX for our users
… and it is easier to implement and the exact opposite of jgraham was saying
orkon: I am not up to date with the new API and I wonder if there are ways we can do this with script evaluation
jgraham: I think there are ways to do it but not sure they are sensible and it would be better to expose this directly in our API
… e.g. if we wanted to do a task after a history event has completed they could do it even if it wasnt initiated via a webdriver API