Meeting minutes
Clarify correct behavior for uploading a folder via "Element Send Keys"
github: w3c/
whimboo: I have noticed this for a issue against for Firefox recently. Firefox doesnt do anything but ChromeDriver uploads all the files in the directory
… so what should we be doing as we could break backwards compat here
automatedtester: I kinda think that we should follow what chromedriver is doing here for everyone
whimboo: This will potentially upload files that people are not expecting here... so we might want to clarify things for users
<shs96c> https://
orkon___: I think we should probably move chromedriver towards to firefox. We should raise a bug and see what happens on the file.
… and with regard to bidi, the validation is left to the client
ACTION: Chromedriver folks to see what happens on a web page when and possible move ChromeDriver to Firefox implementation
Randolf__: this feels like it is OS territory here. I think we should just do something simple and move CHromedriver to just do files and not folders
Serialize WindowProxy with full browsingContext.info and not just context
github: w3c/
whimboo_: This is a follow up to get feedback on the serialising the WindowProxy
… and to share back with clients what the type of the window
… adding this info on the response we can minimize all the round trips back to the client and simplify the interop hopefully
… in puppeteer they cache the window objects
… but we don't expect that in selenium
MaksimSadym: I wonder if its good enough to send back just the frame or top level
… or if we need to pass back a lot more info e.g. parent/children
whimboo_: if we don't want to have the full browsing context info we could add a flag e.g. if it's a top level it returns without the flag and with the frame it has it
jgraham_: we can skip serialising the children. it is a reasonable concern if we are sharing too much info but we can return it with only url and parent
<sadym> We aren't opposed to the suggestion, but I wonder if the justification "X is needed in case of cross-operations between BiDi and Classic to reduce round trips" to extend data / add new commands etc it enough
input.setFiles
github: w3c/
orkon___: We have supplied 2 PRs. One is for the setting the files on an input element and one for picking files
… one question do we need to show the dialog?
… in puppeteer we intercept and then set it without showing it
… any thoughts
jgraham_: there are clear use cases for both for getting the event when the dialog is shown
… we have done things in the pass where we have semi automated tests
… where people might have a human in the loop
… there could be a use case where we are collecting events but the human does the interactions
… there might be times where you want to automate that if you clicked a button that the dialog is loaded and you assert on that event
… I think we should support both use cases
… I don't think subscribing to the even should supress the dialog
… the way this works in classic for alerts is via capabilities and we could use that process
… and we could supress the dialog in a global way. It might make sense to ahve a config for this that surpresses things and in the event we add that it would have come up but was surpressed
orkon___: if we surpess this via a capability... what happens if a user doesn't subscribe or they dont suppress it would it be open all the time?
jgraham_: yes, like alerts
Randolf__: I think that if we do it via capabilities it should be fine
… outside of that we can discuss it on the PR
… is there anything else missing. jgraham_ did have a comment about cancellation. I have followed up on the PR
jgraham_: I will review again
Permission extensions
github: w3c/
orkon___: thiagowfx_web started looking into implementing permissions
… there is a PR in draft that people can start reviewing about how extension methods should be written
… do we want to refine the way we have extensions written or ...?
jgraham_: I haven't looked yet but adding whole modules seems a very clear way for people to add things
… it also has good way to prevent people trampling over
… I think vendor extensions and spec extensions are very different use cases
… we should encourage external specs to define whole modules for their use
orkon___: <describes something about colon>. As for classic permissions only has 1 command so that seems a little much for a whole module
… but I think it could work
gsnedders: To use the permission spec as a idea... we should consider that a spec could extend webdriver and also want to add new capabilities and we should handle that
jgraham_: capabilities is a special case
… if the use case is extending capabilities I think that is already covered
orkon: we have already started looking into this to get the classic across to bidi. if you think we can improve this please comment on the PR
Cookies
<jgraham_> (don't want to extend this topic further, but I always assumed BiDi would move to an event-based model for permissions i.e. you'd get a permissions.Request event with some information)
github: w3c/
orkon___: I was wondering if there are any open issues/blockers for the cookies proposal?
<orkon___> w3c/
lola_: Mike isn't here today but he will be working on them this week. We should hopefully have those comments handled and ready for review later this week
"session.reset" / "session.unsubscribeAll"
github: w3c/
sadym: it would be good to use something like session.reset to clean up the state for tests
… we are already cleaning up tests for WPT <missed rest>
jgraham_: I think in principle this seems ok
… we disucssed internally and we discussed that it would be good to have a mechanism to get a token for certain events and then you only unsubscribe for that set of events
orkon___: I wonder if there is some overlap with the removing the session PR that jgraham_ was working on where restarting a session on the same connect
<sadym> The scenario is to prepare the state for the next test, and re-creating the session with the same websocket connection would work as well, but not sure if there can be some other side effects
jgraham_: the original PR was a lightweight reset of the session
… it clear the object cache but leave the capabilities
… <discusses tokens>
… we should definitely write this up
<jgraham_> RRSAgent: make minutes