[py][bidi] input.setFiles 没有文件检测器,因此本地路径无法在远程浏览器中使用

□ 特点和动机

BiDi 输入. set 文件"与经典文件检测器没有等同性,因此在文件输入中附加一个本地文件在浏览器在另一台机器(Grid,Docker,云提供商)上时无效. 这是经典和BiDI之间的功能差距,而不仅仅是覆盖差距.

在经典下,远程驱动器上的“WebElement.send keys”通过“file deactor”运行给定路径,并在发送密钥前上传到节点:

https://GitHub.com/SeleniumHQ/selenium/blob/trunk/py/selenium/webdriver/remote/webelement.py#L263-L274 (英语).

因此,这与今天的远程浏览器是背道而驰的:

驱动程序. find element(By.ID,"upload"). send keys ("/path/on/my/laptop/test file.txt").

在BiDi下,`输入.set' 文件"将原始路径直接发送到浏览器,在浏览器主机上解决. 没有上传步骤,也没有探测器钩,所以针对远程浏览器的同一呼叫要么失败,要么无声无息地附加:

drivers.input.set files (driver. current window handle, element ref, ["/path/on/my/laptop/test file.txt"]) (中文(简体) ).

这是审查Python BiDi交互代码(# 18007)后产生的. 它并非Python的特有——Java、Ruby、JS和.NET都通过“SetFiles”的路径,因此,无论我们决定什么,都应该适用。

□ 需要考虑的事情

• 现有的“setFiles”测试从未抓住这一点:它们都与本地浏览器相撞,并坚持输入的“值”。 #18007中的新一轮来回测试也是本地独活. 无论是哪种方式,都需要进行具体远程测试。
• 固定是否属于约束(发现本地路径,通过经典的`/session/{id}/file'端点上传,然后将返回的远程路径传到'setFiles'),或者BiDi是否应当生长自己的文件传输原始. 前者在今天工作,但意思是BiDi呼叫取决于经典的端点,这对BiDi唯一的未来来说是尴尬的.
• " setFiles " 是否应该尊重`driver.files detector',或者是否应该要求用户在浏览器主机上放置文件。 如果后者,我们应当清楚地记录这一点,因为典型的行为造成了相反的期望。
• 斯佩克问题:这是否应该与WebDriver BiDi谱一起提出,而不是解决每个约束.

而不是被从经典到BiDi的用户发现.