You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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:
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.
Whether the fix belongs in the bindings (detect a local path, upload it via the classic /session/{id}/file endpoint, then pass the returned remote path to setFiles) 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 setFiles should respect driver.file_detector at 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.
Feature and motivation
BiDi
input.setFileshas 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_keyson a remote driver runs the given paths throughfile_detectorand uploads each one to the node before dispatching the keys:https://github.com/SeleniumHQ/selenium/blob/trunk/py/selenium/webdriver/remote/webelement.py#L263-L274
So this works against a remote browser today:
Under BiDi,
input.setFilessends 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: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
setFilesunchanged, so whatever we decide should apply across bindings.Things to consider
setFilestests never catch this: they all run against a local browser and assert on the input'svalue. The new round-trip tests in [py] add BiDi upload tests that verify files actually reach the server #18007 are also local-only. A remote-specific test would be needed either way./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.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.Filing so the decision is recorded rather than discovered by users migrating from classic to BiDi.