使用文件协议调用 Chrome 中 iframe 中定义的 JavaScript 函数
这个问题与此处提出的问题的完全更新版本非常相似：如何使用文件协议在 Chrome/Webkit 中从一个框架调用 JavaScript 函数到另一个框架 - 不幸的是，这个问题从未真正得到解答。
我有一个 HTML 页面，其中包含 iframe 中的 SVG 图像。 SVG 导出一个 JavaScript API，允许它执行有用的操作（重置为缩放和居中，以“实际大小”显示）。在 iframe 下方，我放置了按钮，用户可以单击该按钮来调用 SVG 中定义的函数。
我的代码如下所示：
function reset() {
document.getElementByID('iframe').contentWindow.reset();
}
它在 Safari、Firefox 甚至 IE 9（支持 SVG - 万岁！）中完美运行。但在 Chrome 上，它失败了：调试器通知我：
对象 [object DOMWindow] 的属性“重置”不是一个函数。
事实上，这似乎确实是事实：尽管“contentWindow”是 DOMWindow 类型，但它没有方法或字段（至少调试器不会向我显示）。即使询问其“文档”字段也会失败（返回 null）。
问题似乎是使用 file:// 协议来传输包含的 HTML 和包含的 SVG。正如我在上面提到的问题中指出的，当尝试访问“contentWindow”时，Chrome 会产生以下错误：
Attempt to accessframe with URL file://[...]/contained.svg fromframe URL 文件://[...]/container.html。域、协议和端口必须匹配。
总的来说，我认为安全性很好；这看起来像是一个出于安全考虑的限制。但在这里，它似乎走得太远了：毕竟，这些是用户文件系统上的文件，就我而言，甚至位于同一目录中。
托管代码不是一种选择 - 它必须驻留在用户的计算机上。我不想告诉人们“只是不要使用 Chrome - 它有愚蠢的安全概念。”
有没有办法解决这个限制？
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?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
当然没办法:)这些文件协议是要由用户显式调用的。正如您所看到的，Web 应用程序绝对不可能允许这样做。
唯一的方法是，如果您“作为用户”允许这种情况发生，如果是这样，您可以通过添加以下命令行参数来启用它：
因此，使用以下命令打开 Chrome： chrome.exe
--allow- file-access-from-files这用于开发。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:
So open up Chrome with: chrome.exe
--allow-file-access-from-filesthis is used for development.感谢@Mohamed Mansour 提供的信息，我能够找到有关此问题的更多详细信息。
Chrome 行为的基本原理是防止恶意制作的页面通过 JavaScript 和内部框架在您不知情的情况下访问您的文件系统内容并将数据上传到互联网 [Chromium 错误 4197，Chromium 错误 47416]。
在我看来，不幸的是 Chromium 团队选择这样做。 Gecko 在打击这个痣方面更加微妙：它将跨页面脚本限制在相同的子目录中 [Mozilla bug 230606，文件协议的同源策略] 。对于用户和开发人员来说，这一结果并不令人意外，而且与 Chrome 的行为相比，产生的焦虑也少得多 — 请阅读 Chromium bug 47416 特别是看看我的意思。
由于这种行为，我不得不修改我的“网站”——它不能托管在互联网上，必须驻留在本地用户的计算机上——以便它弹出一个对话框，告诉用户切换浏览器。这真的太糟糕了 - 我想支持 Chrome，但不能指望我的用户在想要运行我的“网站”时使用晦涩的命令行选项重新启动它。
我在这里发布我的发现，以防其他人在 Chrome 似乎神秘地不适合他们时偶然发现我的问题，并鼓励任何阅读本文的人考虑加星标 Chromium 错误 47416。开发人员痛苦地明确表示，他们不愿意考虑改变 Chrome 的行为，除非明确人们真的关心这个问题。被告知“我不得不告诉用户不要使用 Chrome”并不足以起到鼓励作用。
Thanks to the information offered by @Mohamed Mansour, I was able to find more details on this issue.
The rationale for Chrome's behavior is to prevent a maliciously-crafted page from, through JavaScript and internal frames, accessing the contents of your file system without your knowledge and upload data to the Internet [Chromium bug 4197, Chromium bug 47416].
It is unfortunate, from my point of view, that the Chromium team chose to take things as far as they did. Gecko is a bit more subtle in whacking this mole: it limits cross-page scripts to same-subdirectories [Mozilla bug 230606, Same-origin policy for file protocol]. The result is much less surprising for users and developers and has generated much, much less angst than has arisen over Chrome's behavior — read Chromium bug 47416 in particular to see what I mean.
Because of this behavior, I've had to modify my "website" — which cannot be hosted on the Internet and must reside on local-users' machines — so that it throws up a dialog box telling users to switch browsers. It's really too bad — I'd like to support Chrome but just can't expect my users to relaunch it with an obscure command-line option whenever they want to run my "website."
I'm posting my findings here in case anyone else stumbles across my question when Chrome seems to mysteriously not work for them and also to encourage anyone who reads this to consider starring Chromium bug 47416. The developers have made it painfully clear that they are unwilling to consider changing Chrome's behavior unless it's clear people really care about the issue. Being told "I've had to tell users not to use Chrome" hasn't been enough encouragement.