当浏览器忙于执行一些长时间运行的 JavaScript 时，WebDriver API 阻塞行为

我在文档中的某个地方读到 WebDriver API 是非阻塞的（除了一些像 driver.get 的 API）。因此，执行 WebElement click() 或 isDisplayed() 通常应该是异步的（当然，假设启用了本机事件）。

我有一个简单的 HTML 页面，它执行一个长操作（基本上是一个长循环）。当 JS 执行时，浏览器没有响应，这是预料之中的。但我也注意到，只要浏览器忙于执行脚本，WebDriver API 就会像 click()/isDisplayed()/executeScript() 块一样。

由于 WebDriver 发出的是一个原生的点击事件，而不是一个合成的 JS 事件，我很困惑为什么 API 会阻塞。虽然目前这种行为并没有困扰我，但我想知道在对无响应的页面运行测试时是否可以依赖这种阻塞性质？我在测试中确实使用了条件等待，但想了解幕后发生的情况以及这是否特定于浏览器/操作系统？

我在 Windows 7 上使用 InternetExplorerDriver (IE9) 和 ChromeDriver (Chrome 19) 的 Selenium 2.20.0 中看到了这种行为。

实际上，阻塞 API 与非阻塞 API 的使用是许多 Selenium 库用户争论的焦点。在很多地方，库都会进行“最佳猜测”尝试来阻止，甚至在元素点击时也是如此，但这并不能保证。阻塞和非阻塞之间的这种张力已经详细讨论 https://groups.google.com/forum/?fromgroups#!topic/selenium-developers/WuqiU7cKOTk在开发者社区中，反映在常见问题解答之一 http://code.google.com/p/selenium/wiki/FrequentlyAskedQuestions#Q%3a_WebDriver_fails_to_find_elements_/_Does_not_block_on_page_loa在项目维基中。对于 IE，驱动程序确实会尝试阻止元素点击，并且无论是否成功阻止，这都是一个竞争条件。对于您的特定页面，IE 驱动程序（显然还有 Chrome）正在“赢得”这场比赛，并阻塞直到操作完成。但是，在其他情况下，驱动程序也可能很容易输掉比赛，因此最好在继续代码中的下一步之前使用显式等待其他页面更改。

如果将来出现问题，您可以通过设置页面加载超时 http://selenium.googlecode.com/svn/trunk/docs/api/java/org/openqa/selenium/WebDriver.Timeouts.html#pageLoadTimeout%28long,%20java.util.concurrent.TimeUnit%29提前转到下一个声明。这种方法的一个小挑战是，目前并非所有浏览器都可以实现超时（IE 可以，我不知道 Chrome 是否可以）。