selenium + chrome.fileSystem.chooseEntry =无效的调用页面错误

时间:2016-07-02 03:28:18

标签: javascript google-chrome selenium google-chrome-extension

我正在编写一个Selenium脚本来测试使用Chrome.fileSystem.chooseEntry API选择目录的Chrome应用。当我手动执行此操作时,它工作正常。但是当我在Selenium脚本中执行此操作时,我会收到此错误:

运行fileSystem.chooseEntry时未经检查的runtime.lastError:无效的调用页面。无法从后台页面调用此功能。

关于如何让Selenium和chooseEntry一起玩得很好的想法?

我更新了最新的Chromedriver,但仍然没有运气。我也查看了ChromeOptions,但没有看到任何看起来有用的东西。对于Selenium和chooseEntry来说,互联网似乎没什么好说的。我是Chrome的第51版。

我认为我需要一个特殊的javascript入口点来设置测试的路径值,而不是使用chooseEntry。但我强烈希望我的测试没有单独的代码执行路径。有人有更清洁的解决方案吗?

编辑:根据评论者的要求,这是违规代码:

chrome.fileSystem.chooseEntry({type:'openDirectory'},function(entry) {
  chrome.fileSystem.getWritableEntry(entry,function(writeable_entry) {
      console.log("got writeable entry");
  });
 }, function(e) { errorHandler(e); });
编辑#2:我已经使用了特殊的javascript入口点hack。在手动模式下 - 即,不在Selenium下运行 - 我运行执行chooseEntry的代码,然后使用retainEntry API获取条目ID。我在我的javascript中添加了一个入口点以获取条目ID并调用restoreEntry API将其重新转换为条目。我还修改了我的代码,所以如果设置了这个条目对象,那么使用它作为文件,而不是调用chooseEntry。最后,我修改了我的Selenium脚本,在运行脚本的其余部分之前调用restoreEntry入口点。

这并不理想,因为现在我的测试代码执行路径与我实际的人工控制代码执行路径有些不同。但至少它让我现在使用Selenium脚本。当然,如果有人能想出解决这个问题的非可怕方法,我很乐意听到它。

编辑#3:Per @ Xan的评论,纠正了我的术语"扩展"到" Chrome应用。"

1 个答案:

答案 0 :(得分:0)

我只能提供这种可怕的黑客攻击。对于OSX下的Chrome应用,我创建了文件夹收藏夹,并使用机器人按键导航并选择“收藏夹”#39;应用程序所需的文件夹。唯一可能的兑换因素是它确实镜像了与文件界面的有效/可能的实际人工交互。

{{1}}