webdriver的API拦截行为时，浏览器正在执行一些长期运行的JavaScript [英] WebDriver API blocking behavior when browser is busy executing some long running JavaScript

问题描述

我在这的webdriver的API的文档阅读的地方是非阻塞（除了少数像driver.get）。因此，执行WebElement点击（）或isDisplayed（）一​​般应异步（假设原生事件被允许的，当然）。

I read somewhere in the docs that WebDriver API's are non blocking (except for a few like driver.get). So performing a WebElement click() or isDisplayed() should generally be asynchronous (assuming native events are enabled, of course).

我有一个执行长操作（基本上是一个长循环）一个简单的HTML页面。而对JS执行，浏览器没有响应，预计。但是，我也注意到，webdriver的API的像click（）/ isDisplayed（）/ executeScript（）块，只要浏览器正忙于执行脚本。

I have a simple HTML page that performs a long operation (basically a long loop). While the JS executes, the browser is unresponsive which is expected. But I also noticed that WebDriver API's like click()/isDisplayed()/executeScript() block as long as the browser is busy executing the script.

由于是的webdriver发出本机事件的点击，而不是合成的JS事件，我百思不得其解，为什么API块。虽然present这种行为是不是困扰着我，我想知道这是否阻塞性质可以运行针对反应迟钝的网页测试时不能依赖？我在我的测试使用条件的等待，而是想了解下罩会发生什么，如果这是浏览器/操作系统的具体？

Since WebDriver is issuing a native event for the click and not a synthesized JS event, I am puzzled why the API blocks. Although at present this behavior is not bothering me, I want to know if this blocking nature can be relied upon when running tests against unresponsive pages? I do use conditional waits in my tests, but would like to understand what happens under the hoods and if this is Browser/OS specific?

我在Windows 7上看到这种行为硒2.20.0与InternetExplorerDriver（IE9）和ChromeDriver（铬19）。

I am seeing this behavior in Selenium 2.20.0 with InternetExplorerDriver (IE9) and ChromeDriver (Chrome 19) on Windows 7.

推荐答案

其实，使用阻塞与非阻塞API争为硒图书馆的许多用户的一个点。有很多的，其中库做的是最佳猜测企图阻止，甚至在元素点击的地方，但它不能保证。阻塞和非阻塞之间的矛盾一直在长度开发者社区中，并反映在<一个href=\"http://$c$c.google.com/p/selenium/wiki/FrequentlyAskedQuestions#Q%3a_WebDriver_fails_to_find_elements_/_Does_not_block_on_page_loa\"相对=nofollow>常见问题之一，在项目wiki 的。在IE浏览器的情况下，驾驶者试图在元素点击阻止，以及是否在阻止或无法成功，这是一个竞争状态。在您的特定页面的情况下，IE的驱动程序（和Chrome显然）是中奖那场比赛，阻塞直到操作完成。但是，驱动程序可以很容易失去在其他情况下那场比赛，所以最好继续在你的code中的下一步之前使用其他网页的变化明确的等待。

Actually, the use of a blocking vs. non-blocking API is a point of contention for many users of the Selenium library. There are a lot of places where the library does a "best guess" attempt at blocking, even on element clicks, but it's not guaranteed. This tension between blocking and non-blocking has been discussed at length among the developer community and is reflected in one of the FAQs in the project wiki. In the case of IE, the driver does attempt to block on element clicks, and it's a race condition whether it succeeds in blocking or not. In the case of your specific page, the IE driver (and Chrome apparently) are "winning" that race, blocking until the operation is complete. However, the driver could just as easily lose that race in other cases, so it's best to use explicit waits for other page changes before proceeding to the next step in your code.

如果它成为在未来的一个问题，你也许可以通过设置<一来缓解这种href=\"http://selenium.google$c$c.com/svn/trunk/docs/api/java/org/openqa/selenium/WebDriver.Timeouts.html#pageLoadTimeout%28long,%20java.util.concurrent.TimeUnit%29\"相对=nofollow>页面加载超时以移动到下一个语句前面。这种方法的一个小的挑战是，并非所有的浏览器可以实现超时目前（IE浏览器，我不知道关于Chrome）。

If it becomes a problem in the future, you might be able to mitigate this by setting a page load timeout to move on to the next statement earlier. One small challenge with this approach is that not all browsers may implement the timeout currently (IE does, I don't know about Chrome).

这篇关于webdriver的API拦截行为时，浏览器正在执行一些长期运行的JavaScript的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！