Ability to test and fill out file inputs

[OrKoN]

It is mentioned in the roadmap spreadsheet, but not tracked as an issue here.

It potentially includes:

• ability to detect that a file selection dialog would be opened without showing the dialog
• ability to cancel the dialog or select one or multiple files
• ability to set files on an input without triggering the dialog

CDP equivalent: DOM.setFileInputFiles, Page.fileChooserOpened, Page.setInterceptFileChooserDialog

[OrKoN]

assigning to @jrandolf as discussed before.

[css-meeting-bot]

The Browser Testing and Tools Working Group just discussed Ability to upload files and fill out file inputs.

The full IRC log of that discussion

<AutomatedTester> Topic: Ability to upload files and fill out file inputs
<orkon> q+
<AutomatedTester> github: https://github.com//issues/494
<AutomatedTester> ack next
<AutomatedTester> orkon: We started working on this feature. THere are some open topics on this
<AutomatedTester> ... context: we tried to implement a method to set the file to the dialog
<shs96c> q+
<AutomatedTester> ... and we need to get the events with this
<AutomatedTester> ...q1: is the interception of the dialog should be doable through the current mechanisms. Are people ok with this?
<AutomatedTester> ack next
<jgraham> https://github.com//pull/514
<AutomatedTester> shs96c: Not all UIs show the dialog. There might not be able to get the file upload. For the local case this is really easy to do
<orkon> q+
<AutomatedTester> ... for remote the clients are going to need to be able to send the file across intermediary nodes
<jgraham> q+
<AutomatedTester> ... for the UIs doing text boxes they assume the file exists on the local file system
<AutomatedTester> ... but I think the remote case needs to be handled.
<AutomatedTester> ack next
<AutomatedTester> ... for selenium people hate the sendkeys that doesn't upload the file if it's just a text box
<AutomatedTester> orkon: should we intercept the dialog and be part of the event subscription
<AutomatedTester> shs96c: For the remote case we take the file, upload it, get the new file address and they type the new file path is done part of the sendkeys command
<AutomatedTester> ... if set file input had the file name and file contents as the payload it would solve this problem
<AutomatedTester> ack next
<AutomatedTester> jgraham: for set files I think it would be fine to bypass dialogs
<orkon> q+
<AutomatedTester> ... if the dialog blocks the browser there should be a way to probably send that out but it might not be cancellable.
<shs96c> q+
<whimboo> the file dialog is a native dialog from the OS and we cannot handle that in Firefox
<AutomatedTester> ... we could have an event for "a file dialog has appeared, please send files or cancel" so we don't block the UI
<shs96c> q-
<shs96c> q+
<AutomatedTester> ack next
<AutomatedTester> orkon: we envisioned the workflow that the person would intercept the dialog and then set the file path in the dialog
<AutomatedTester> ... and then people could choose what to do next
<AutomatedTester> ... we suppress the dialog from appearing on screen
<AutomatedTester> ack next
<AutomatedTester> shs96c: in selenium the uploads can be dependent on the UA as it can block the browser
<AutomatedTester> ... we were block the dialog from loading. <describes the entirely convoluted way to make it work in IE in the past>
<AutomatedTester> ... and this didn't work in Firefox
<orkon> q+
<AutomatedTester> ack next
<AutomatedTester> orkon: this is why we want to discuss it. We want to intercept it. We can stop here and then I will come back with an example.
<AutomatedTester> shs96c: <describes a use case where we capture an display:none interaction causing a dialog to appear>
<shs96c> In that case, being able to block the dialogue from opening would be wonderful
<jgraham> ScribeNick: jgraham
<jgraham> RRSAgent: make minutes
<RRSAgent> I have made the request to generate https://www.w3.org/2023/09/14-webdriver-minutes.html jgraham

[css-meeting-bot]

The Browser Testing and Tools Working Group just discussed Ability to upload files and fill out file inputs (contd), and agreed to the following:

• ACTION: file an issue on how to handle alerts if there aren't any subscribers to the events

The full IRC log of that discussion

<AutomatedTester> Topic: Ability to upload files and fill out file inputs (contd)
<AutomatedTester> github: https://github.com//issues/494
<jgraham> ScribeNick: AutomatedTester
<orkon> q+
<AutomatedTester> ack next
<AutomatedTester> orkon: We have a use case that a dialog would be shown to a user. We would like to have an event that shows that a dialog would appear. We would surpress the the dialog from loading
<AutomatedTester> ... we would then notify the user so they can then decide to dismiss the dialog or complete the form
<AutomatedTester> ... we also want to have people to automatically handle the dialog if people aren't expecting it
<AutomatedTester> ... the interception of the dialog would be happen if the person subscribes to the events
<AutomatedTester> q?
<jgraham> q+
<jgraham> https://html.spec.whatwg.org/#show-the-picker,-if-applicable
<AutomatedTester> ack next
<AutomatedTester> jgraham: I have found the relevant part of the html spec for this
<AutomatedTester> ... we would effectively override steps 2 and 3
<AutomatedTester> ... there is some interesting edge case here whether the element fets the cancel event
<AutomatedTester> ... and if you didn't respond that's a case that wont happen with a real dialog
<orkon> q+
<AutomatedTester> ... I think if you are not subscribed to the events that we should cancel the dialog automatically
<AutomatedTester> ... the worst case is that we get the dialog and can't handle this
<AutomatedTester> orkon: we have the same situation in alerts and we should handle in the same way
<AutomatedTester> jgraham: yes, we need to be able to handle this. currenetly people need to subscribe and handle the alerts as they appear but we should probably go back and check the spec in bidi here
<AutomatedTester> jgraham: we should sort this with alerts
<AutomatedTester> shs96c: we should do what classic does here
<AutomatedTester> jgraham: we should raise an issue here and get it sorted
<orkon> q+
<AutomatedTester> ack next
<AutomatedTester> orkon: there could be cases for hybrid automation
<AutomatedTester> ... we should automatically throw errors here
<jgraham> ACTION: file an issue on how to handle alerts if there aren't any subscribers to the events
<jgraham> q+
<AutomatedTester> ack next
<AutomatedTester> jgraham: the hybrid case is important here
<AutomatedTester> ... <explains a use case>
<AutomatedTester> ... and it not working in Safari is something we need to be aware of. We should probably do what shs96c said and follow the capability
<AutomatedTester> q?

[css-meeting-bot]

The Browser Testing and Tools Working Group just discussed Ability to upload files and fill out file inputs.

The full IRC log of that discussion

<AutomatedTester> Topic: Ability to upload files and fill out file inputs
<orkon> q+
<AutomatedTester> github: https://github.com//issues/494
<orkon> 1. Interception enabled by the event subscription to the input.fileDialogIntercepted event.... (full message at <https://matrix.org/_matrix/media/v3/download/matrix.org/zhgDeKqAtTFNZpkaAtotzLTF>)
<AutomatedTester> ack next
<orkon> this is the consensus
<jgraham> RRSAgent: Make minutes
<RRSAgent> I have made the request to generate https://www.w3.org/2023/09/14-webdriver-minutes.html jgraham

[css-meeting-bot]

The Browser Testing and Tools Working Group just discussed input.setFiles.

The full IRC log of that discussion

<jgraham_> Topic: input.setFiles
<jgraham_> github: https://github.com//issues/494
<jgraham_> ScribeNikck : jgraham_
<jgraham_> orkon: In classic this is doen via sendkeys, which is part of actions
<jgraham_> s/ScribeNikck/ScribeNick/
<jrandolf> q+
<jgraham_> ScribeNick: orkon
<jgraham_> q+
<jgraham_> ack next
<jgraham_> ack next
<orkon> ScribeNick: orkon
<orkon> jgraham_ (IRC): I think it does not need to be part of actions. Like Henrik said element send keys is a separate command.
<orkon> jgraham_ (IRC): the implementation can distinguish between the cases and invoke setFiles because in the clients it is not possible to send keys as part of the input sequence
<orkon> jgraham_ (IRC): I suspect if you send key events in classic while focused on an input element, probably nothing would happen
<orkon> q?
<orkon> jgraham_ (IRC): will take a look at PRs
<jgraham_> RRSAgent: make minutes
<RRSAgent> I have made the request to generate https://www.w3.org/2023/10/11-webdriver-minutes.html jgraham_
<jgraham_> RRSAgent, bye
<RRSAgent> I see no action items
<jgraham_> Zakim, bye
<Zakim> leaving. As of this point the attendees have been JimEvans, AutomatedTester_, thiagowfx, orkon, cb, whimboo, jrandolf, lightning00blade, shs96c, jgraham, gsnedders
<whimboo> Zakim (IRC): you missed me given that I clearly said present+

[css-meeting-bot]

The Browser Testing and Tools Working Group just discussed input.setFiles.

The full IRC log of that discussion

<AutomatedTester_> Topic: input.setFiles
<AutomatedTester_> github: https://github.com//issues/494
<orkon___> q+
<AutomatedTester_> ack next
<AutomatedTester_> orkon___: We have supplied 2 PRs. One is for the setting the files on an input element and one for picking files
<jgraham_> q+
<AutomatedTester_> ... one question do we need to show the dialog?
<AutomatedTester_> ... in puppeteer we intercept and then set it without showing it
<AutomatedTester_> ... any thoughts
<AutomatedTester_> ack next
<AutomatedTester_> jgraham_: there are clear use cases for both for getting the event when the dialog is shown
<AutomatedTester_> ... we have done things in the pass where we have semi automated tests
<AutomatedTester_> ... where people might have a human in the loop
<AutomatedTester_> ... there could be a use case where we are collecting events but the human does the interactions
<AutomatedTester_> ... 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
<orkon___> q+
<AutomatedTester_> ... I think we should support both use cases
<AutomatedTester_> ... I don't think subscribing to the even should supress the dialog
<Randolf__> q+
<AutomatedTester_> ... the way this works in classic for alerts is via capabilities and we could use that process
<AutomatedTester_> ... 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
<AutomatedTester_> ack next
<AutomatedTester_> 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?
<AutomatedTester_> jgraham_: yes, like alerts
<AutomatedTester_> ack next
<AutomatedTester_> Randolf__: I think that if we do it via capabilities it should be fine
<AutomatedTester_> ... outside of that we can discuss it on the PR
<AutomatedTester_> ... is there anything else missing. jgraham_ did have a comment about cancellation. I have followed up on the PR
<AutomatedTester_> jgraham_: I will review again
<AutomatedTester_> q?