[py][bidi] input.setFiles has no file detector, so local paths do not work against a remote browser
Feature and motivation
BiDi input.setFiles has no equivalent of the classic file detector, so attaching a local file to a file input does not work when the browser is on another machine (Grid, Docker, cloud provider). This is a functional gap between classic and BiDi, not just a coverage gap.
Under classic, WebElement.send_keys on a remote driver runs the given paths through file_detector and uploads each one to the node before dispatching the keys:
So this works against a remote browser today:
driver.find_element(By.ID, "upload").send_keys("/path/on/my/laptop/test_file.txt")Under BiDi, input.setFiles sends the raw path straight through to the browser, which resolves it on the browser host. There is no upload step and no detector hook, so the same call against a remote browser either fails or silently attaches nothing:
driver.input.set_files(driver.current_window_handle, element_ref, ["/path/on/my/laptop/test_file.txt"])This came out of reviewing the Python BiDi interaction code (#18007). It is not Python-specific — Java, Ruby, JS, and .NET all pass paths through to setFiles unchanged, so whatever we decide should apply across bindings.
Things to consider
- The existing
setFilestests never catch this: they all run against a local browser and assert on the input'svalue. The new round-trip tests in #18007 are also local-only. A remote-specific test would be needed either way. - Whether the fix belongs in the bindings (detect a local path, upload it via the classic
/session/{id}/fileendpoint, then pass the returned remote path tosetFiles) or whether BiDi should grow a file-transfer primitive of its own. The former works today but means a BiDi call depends on a classic endpoint, which is awkward for a BiDi-only future. - Whether
setFilesshould respectdriver.file_detectorat all, or whether users should be expected to place files on the browser host themselves. If the latter, we should document that clearly, because the classic behaviour sets the opposite expectation. - Spec question: whether this should be raised with the WebDriver BiDi spec rather than solved per-binding.
Filing so the decision is recorded rather than discovered by users migrating from classic to BiDi.
Source: SeleniumHQ/selenium