使用文件协议调用Chrome中iframe中定义的JavaScript函数 [英] Call a JavaScript function defined in an iframe in Chrome using the file protocol

问题描述

这个问题与此处提出的问题的完全更新版本非常相似：—不幸的是，这个问题从来没有得到真正的答案。

我有一个HTML页面，其中包含一个iframe中的SVG图像。 SVG导出一个JavaScript API，允许它做有用的事情（重置为放大和居中，以实际大小显示）。在iframe下面，我已经放置了按钮，用户可以通过该按钮点击SVG中定义的功能。

我的代码如下所示：

  function reset（）{ 
 document.getElementByID（'iframe'）。contentWindow.reset（）; 
} 
  

它在Safari，Firefox甚至IE 9中都能很好地工作（支持SVG - 万岁！）。但在Chrome上，它失败了：调试器告诉我：
$ b

对象[对象DOMWindow]的属性'reset'不是函数

code>。

实际上，似乎确实如此：即使'contentWindow'是DOMWindow类型，它也没有方法或字段至少，不是调试器会显示我）。甚至要求其文档字段失败（产生空值）。

似乎是使用file：//协议将包含HTML和包含的SVG。正如我在上面提到的问题中所指出的那样，当尝试访问'contentWindow'时Chrome会产生以下错误：

尝试访问框架与URL文件：// [...] /contained.svg与URL文件：// [...] /container.html。域，协议和端口必须匹配。

总的来说，我认为安全性很好。这看起来像是一个安全启发的限制。但是在这里，它似乎已经太过分了：毕竟，这些都是用户文件系统上的文件，在我的情况下，甚至在同一个目录中。

托管代码不是一个选项 - 它必须驻留在用户的机器上。我讨厌不得不告诉人们只是不要使用Chrome浏览器 - 它有着愚蠢的安全观念。

有没有办法解决这个限制？

解决方案

当然，这是没有办法的:)这些文件协议意味着被用户明确地调用。如您所见，Web应用程序绝对没有办法允许这样做。

要做到这一点的唯一方法是如果您作为用户允许它如果是这样，可以通过添加以下命令行参数来启用该功能：

  //默认情况下，file：// URI不能读取其他文件：// URI。对于需要旧测试行为的开发者来说，这是一个
 //覆盖。 
  - 允许文件访问从文件
  

chrome.exe - 允许从文件访问文件这是用于开发的。

This question is extremely similar to the fully-updated version of the question asked here: How to call a JavaScript function from one frame to another in Chrome/Webkit with file protocol — unfortunately, that question was never actually answered.

I have an HTML page that contains an SVG image in an iframe. The SVG exports a JavaScript API that allows it to do useful things (reset to zoomed and centered, display at "actual size"). Below the iframe, I've put buttons that the user can click on that call through to the functions defined in the SVG.

My code looks like this:

function reset() {
  document.getElementByID('iframe').contentWindow.reset();
}

It works perfectly in Safari, Firefox, and even IE 9 (which supports SVGs - hooray!). But on Chrome, it fails: the debugger informs me that:

Property 'reset' of object [object DOMWindow] is not a function.

And indeed, there does seem to be truth to that: even though 'contentWindow' is of type DOMWindow, it has no methods or fields (at least, not that the debugger will show me). Even asking for its 'document' field fails (yields null).

The rub appears to be the use of the file:// protocol to transfer both the containing HTML and the contained SVG. As noted in the question I referenced above, Chrome produces the following error when the attempt to access 'contentWindow' is made:

Attempt to access frame with URL file://[...]/contained.svg from frame with URL file://[...]/container.html. Domains, protocols and ports must match.

In general, I think security is great; this looks like a security-inspired restriction. But here, it seems to have gone too far: these are files on the user's filesystem, after all, and in my case, are even in the same directory.

Hosting the code is not an option - it must reside on the user's machine. I'd hate to have to tell people "just don't use Chrome - it has silly notions of security."

Is there no way to work around this restriction?

解决方案

Of course there is no way :) These file protocols are meant to be explicitly called by the user. There is absolutely no way for a web application to allow that, as you have seen.

The only way to do that is if you "as a user" allowed that to happen, if so, you can enable that by adding the following command line parameter:

// By default, file:// URIs cannot read other file:// URIs. This is an
// override for developers who need the old behavior for testing.
--allow-file-access-from-files

So open up Chrome with: chrome.exe --allow-file-access-from-files this is used for development.

这篇关于使用文件协议调用Chrome中iframe中定义的JavaScript函数的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！