Meeting minutes
<jimevans> join #webdriver
Add a command to the "webExtension" module to retrieve a list of all the installed webextensions
github: w3c/
whimboo: since we the extension install/uninstall. THe webext team wants to start using this.
… they have suggested that we add a new command to get list of exts
… it would be good to get this commands to improve the testability
… should we return the lists of all the addons or just the users addons?
… later we can add a list prefix to get the vendor addons
… [mentions browser specific issues for firefox]
rob: I assume addons to not working the same across different browsers. If the addons are installed
orkon: puppeteer has the ability and webdriver bidi has the ability to install/uninstall
… I think this sounds good to us, we think that restricted to things that are only installed during the webdriver session but that's due to privacy concerns
whimboo: regarding the properties that can be an issue but we need to find fimiliar properties and return that. we need to make sure we don't have clashes between our implemtations
… I am not sure if we want to add this for classic or just leave it for bidi
… as it can help clean up tests correctly
<Rob> re: "find similar properties" sure, but I suppose that e.g., Chrome and Edge use different IDs which should be the unique identifier, even if the extension itself is the same across vendors, because we have different "stores"
orkon: we don't need to add this to classic at the moment unless there is a strong need for it for classic
<Rob> Re: "we think that restricted to things that are only installed during the webdriver session but that's due to privacy concerns" - Agree
orkon: I think that returning a list of addons that were installed during the session. let's use noncontroversial properties and build off that
Access downloaded file content.
github: w3c/
sadym: we had a use case raised where someone downloaded a file and wanted to check the contents
… do we want to have a mechanism for progress and a way to assert the contents
… puppeteer/playwright has a way of specifying the directory
Automatedtester: I don't think the file contents should be solved by this working group. We should tell people that it is downloaded and where it is and thats it
sadym: what about selenium grid?
automatedtester: we can have a grid endpoint if poeple want to download the file and not have it solved in this working group. it's mostly for intermediary nodes to solve
sadym: so we can just a
have capability for the download
jgraham: If people turned on the response bodies then they would be able to go download it
… if you're wanting it to be downloaded and then access the file then there can be use cases for the client to solve it
… but I think getting response bodies working better would be the best first step
<Rob> misread!
whimboo: what would be important to have a capability for each user context for when tests are running parallel
<jgraham> (I suggest we don't use the term "capability" for things that are actually configurable per user context)
whimboo: once the session is ended should we delete the files?
Rob: is download to a local file system is the most important part. or to remote
… this complicates things for doing the download "twice"
… if the file is downloaded properly but not accessible it can create a DOS scenario by filling the disk space
whimboo: about download progess, how often does this get emited?
… we dont want to emit these too often
… we could do them in 10% increments
sadym: I will go look and get back to you
<jgraham> For test use cases the download progress notification are a footgun, since they will differ between browsers and test runs
<jgraham> They make more sense for other use cases
AutomatedTester: So it looks the consensus we want an event for progress (how often TBD), event for download complete and we want to have response bodies improved
… for downloaded files we still want to figure that out
<Rob> Even saying 10% increments might be challenging (downloading a 78-byte file - do you emit on every 7.8 bytes?) We would need to be very concrete
orkon: we should probably add a way to disable downloads
Rob: If a person disabled the download, would it prevent the download from hitting the disk since you could probably see the response bodies
jgraham: technincally that is already allowed. THere is no guarantee what happens to the file
… in practise clients would complain but there is a lot of undefined behaviour so we need to be a lot more precise
Specify `acceptInsecureCerts` per user context
github: w3c/
sadym: we have discussed in the PR quite heavily
… jgraham has questioned when should we revert the acceptInsecureCerts when the session for that user context disappears
jgraham: If there was a user context that existed before the session and then set it we should revert it
<Rob> re: webdriver before-after state being reset: agree
jgraham: there is a security reason for making sure we revert when the session is closed
… the lifetime of the config should be the lifetime of that session
… question is if session a sets X and session b extends it but it's a no op and then close the session does it affect all the sessions on the revert
<jgraham> If session A sets the state and then session B sets basically the same state, but it's a noop, and then session A is closed, should it be extended to the lifetime of session B?
orkon: in sadym in PR the config is set when the user context is created. are you wanting to move back to setting the config separatrely from the session
jgraham: ok, we don't want the latter, I was just calling this out
<sadym> 1. are we fine with "it's implementation-specific"?
<sadym> 2. Should we allow setting the `setAcceptInsecureCerts` flag only if the cabaility is not set to reduce confusion and overrides?
jgraham: in terms of t
… the spec. In classic we say "do this thing"
… the ideal spec would hook into fetch and explain it does this thing when the navigate happen
… instead of doing "do an implementation defined thing here"
… for the capabilities here set here shuld be the default and then allow people to override
… I think it would be ok to have different behaviour if this is too difficult to implement
Specify `unhandledPromptBehavior` per user context
github: w3c/
sadym: how should we handle this? I think we should allow this to override the default everywhere
jgraham: I remember this being very complicated. In general I agree with you here
… I think it will be fine to override here
… we need to see what would happen when we override in multiple sessions
<jgraham> RRSAgent: make minutes
Add commands to collect and retrieve response bodies
github: w3c/
jdescottes: we have a PR to impelemt the collect/retrieve response bodies
… there are still osme questions outstanding?
… should we allow filtering of URLS to limit what people can do?
… how should the cache be partitioned here
… if we only have 1 cache on the remote end that can simplify things but we need to agree
orkon: for the URL problem filter could be hard but if we do it by max size that would be easier
<jgraham> It's not supported in Puppeteer or Playwright right? If that's true it's not surprising it's not used.
orkon: and if we have it global then it would make life much easier
jdescottes: there are way that we can try do it to block images
jgraham: the HTTP archive crawler is a good example so we might want to filter on mimetype might be better
… if we are doing things in the global state that it create a lot of problems... like if we add a filter how do we know if we can remove it later?
… I am worried we are going to say "it's simpler if it is global" and then realise it was a mistake
orkon: about the URL, I would like to see if use cases
<jgraham> Happy to start with MIME type.
orkon: I don't think clients will care if it is left in the cache
… usually if there is precise control
… if you don't clear the bodies or the filter, we haven't seen that cause issues as they can clear it up eventually
jdescottes: to summarize I will update the PR to use MIME types
… and if we have global cache then it's less critical to provide the collector id
<jgraham> RRSAgent: make minutes