我在文档中的某处读到WebDriver API是非阻塞的（除了少数像driver.get）。因此，执行WebElement click（）或isDisplayed（）通常应该是异步的（假设当然启用了本机事件）。
我有一个执行长操作的简单HTML页面（基本上是一个长循环）。当JS执行时，浏览器没有响应，这是预期的。但我也注意到，只要浏览器忙于执行脚本，WebDriver API就像click（）/ isDisplayed（）/ executeScript（）一样。
由于WebDriver正在为点击而不是合成的JS事件发布本机事件，我很困惑为什么API会阻塞。虽然目前这种行为并没有困扰我，但我想知道在针对无响应的页面运行测试时是否可以依赖这种阻塞性质？我在测试中使用了条件等待，但是想了解底层会发生什么，以及这是否特定于浏览器/操作系统？
我在Selenium 2.20.0中看到了这种行为，其中包括Windows 7上的InternetExplorerDriver（IE9）和ChromeDriver（Chrome 19）。
答案 0 :(得分：5)
实际上，使用阻塞与非阻塞API是Selenium库的许多用户争论的焦点。在很多地方，图书馆会进行“最佳猜测”尝试阻止，即使是元素点击，但它无法保证。阻止和非阻塞之间的这种紧张关系在开发人员社区中已discussed at length，并反映在项目维基中的one of the FAQs中。在IE的情况下，驱动程序确实试图阻止元素点击，并且无论是否成功阻止都是竞争条件。对于您的特定页面，IE驱动程序（显然是Chrome）正在“赢得”该竞赛，直到操作完成后才会阻止。但是，在其他情况下，驱动程序可能很容易丢失该竞争，因此在继续执行代码中的下一步之前，最好使用显式等待其他页面更改。
如果将来成为问题，您可以通过设置page load timeout来继续前面的下一个语句来缓解这个问题。这种方法的一个小挑战是，并非所有浏览器都可以实现当前的超时（IE确实如此，我不知道Chrome）。