[bidi] setFiles tests assert only on the input value, never that the file was uploaded (all bindings)

[AutomatedTester]

Feature and motivation

Every binding's input.setFiles test asserts only on the file input's value property. That shows the filename string was accepted; it does not show the file was attached or that its bytes were transmitted. A setFiles implementation that sent the filename but dropped the file would pass all of these tests.

The classic upload tests do prove the round trip — they submit the form and assert on what the upload endpoint echoed back into the target iframe, e.g. py/test/selenium/webdriver/common/upload_tests.py:41-48 and the corresponding tests in the other bindings.

Current setFiles tests, all value-only:

• Java — java/test/org/openqa/selenium/bidi/input/SetFilesCommandTest.java
• Ruby — rb/spec/integration/selenium/webdriver/bidi/protocol/input_spec.rb
• JS — javascript/selenium-webdriver/test/bidi/setFiles_command_test.js
• .NET — dotnet/src/webdriver/BiDi/Input/InputModule.cs (consumers)

#18007 adds round-trip coverage on the Python side (set_files, submit, then assert the endpoint echoed back both the filename and the file content) plus a test that types into a text field and attaches a file in one flow. This issue is the parity follow-up for the other bindings.

Things to consider

• The shared common/src/web/upload.html fixture has a file input and a submit button but no text field, so a combined type-and-upload test needs either a different fixture or a change to that one. I avoided changing it in [py] add BiDi upload tests that verify files actually reach the server #18007 — see the next point.
• java/test/org/openqa/selenium/environment/webserver/UploadHandler.java reuses a single values map across all multipart parts (line 59: values is created once outside the loop, and allParts.add(values) adds the same reference repeatedly). Adding another form part to upload.html would therefore concatenate that part's content into what the handler returns, probably breaking Java's existing upload assertions. Worth fixing that handler first if we want a shared fixture with more than one field. Note the Python test server (py/test/selenium/webdriver/common/webserver.py:177-202) echoes the whole multipart body instead, so it does not have this problem — the two servers behave differently here.
• Asserting on the file content rather than only the filename is what makes these tests non-vacuous. In [py] add BiDi upload tests that verify files actually reach the server #18007 I verified this by temporarily passing an empty file list and confirming the test fails; worth doing the same when porting.
• Also worth deciding whether these belong next to each binding's existing BiDi input tests or alongside its classic upload tests.

[titusfortner]

Ruby already has one test - https://github.com/SeleniumHQ/selenium/blob/trunk/rb/spec/integration/selenium/webdriver/bidi/protocol/input_spec.rb#L101

But doesn't have the multiple file test; we can add that.

[MrSuddenJoy]

Screw ruby. Its sheer shit. Period.

[yashp676]

Hi @AutomatedTester, I'd like to pick up the Java part of this if you're happy for someone else to take it.

Proposed approach, as two small PRs:

1. UploadHandler fix: create a new values map per multipart part instead of reusing one instance, so upload.html can safely have more than one field without breaking the existing Java upload assertions.
2. SetFilesCommandTest: add round-trip assertions matching [py] add BiDi upload tests that verify files actually reach the server #18007 (set files, submit, assert the echoed filename and content), including the multiple-file case @titusfortner mentioned for Ruby. I'll confirm the test is non-vacuous by passing an empty file list and checking that it fails.

One question: would you prefer the new tests to stay in bidi/input/SetFilesCommandTest.java, or to sit alongside the classic upload tests? I'm happy to follow whatever works for the other bindings.

[titusfortner]

@yashp676 take a look at how the other tests are structured in Java, @pujagani has been doing work there and may help. You can also find us on #selenium-tlc channel in our Slack if you want to discuss: https://inviter.co/seleniumhq

[yashp676]

Thanks @titusfortner! I'll go through the existing Java BiDi tests to follow their structure, and join #selenium-tlc on Slack.

@pujagani, I'd appreciate any pointers you have. I'll share my approach before opening a PR.

[yashp676]

Opened #18025 for the UploadHandler part of this.

Worth flagging: separating the maps alone makes testMultipleFileUploading fail. That test relied on the three file parts sharing one map so their contents concatenated into a single content` value that findFirst() returned. The PR therefore also collects every part named upload instead of only the first, which preserves the existing behaviour while parsing each part correctly.

UploadTest-chrome (6 tests) and SetFilesCommandTest-chrome (4 tests) both pass locally.

I'll follow up with the round-trip assertions for SetFilesCommandTest once this lands.