我以为我之前找到了解决方案(请参阅我的blog):
如果您获得JavaScript(或者应该是JScript)错误“无法从释放的脚本执行代码” - 尝试移动头部中的任何元标记,以便它们位于脚本标记之前。
...但根据最新的博客评论之一,我建议的修复可能不适用于所有人。我认为这对开放StackOverflow社区来说是一个很好的....
导致错误的原因是“无法从已释放的脚本执行代码”以及解决方案/解决方法是什么?
答案 0 :(得分:33)
当您调用在不再存在的窗口或框架中创建的函数时,会出现此错误。
如果您事先不知道窗口是否仍然存在,您可以尝试使用try / catch来检测它:
try
{
f();
}
catch(e)
{
if (e.number == -2146823277)
// f is no longer available
...
}
答案 1 :(得分:19)
听起来你在某些标签的处理方式上遇到了一个错误/问题,或者你对试图执行方法的已发布对象有所引用。
首先,我会根据建议here以及其他许多地方,在任何<meta>
代码之前移动任何<script>
代码。
然后检查您是否遇到过here页面/安全问题。
答案 2 :(得分:18)
当处理脚本的“父”窗口(即:关闭)时会引发错误,但会调用对仍然保留的脚本(例如在另一个窗口中)的引用。 Even虽然'对象'仍然存在,但它想要执行的上下文却不是。
它有点脏,但它适用于我的Windows边栏小工具:
以下是一般概念: 'main'窗口设置了一个函数,它将评估一些代码,是的,这是丑陋的。 然后'child'可以调用这个“构建器函数”(它绑定到主窗口的范围/)并返回一个也绑定到'main'窗口的函数。当然,一个明显的缺点是,“反弹”这个功能无法在看似定义的范围内进行封闭......无论如何,足够的喋喋不休:
这是部分伪代码,但我在Windows边栏小工具上使用它的一个变体(我一直这么说,因为边栏小工具在“无限制区域0”中运行,这可能 - 或可能不会 - 改变方案很大。)
// This has to be setup from the main window, not a child/etc!
mainWindow.functionBuilder = function (func, args) {
// trim the name, if any
var funcStr = ("" + func).replace(/^function\s+[^\s(]+\s*\(/, "function (")
try {
var rebuilt
eval("rebuilt = (" + funcStr + ")")
return rebuilt(args)
} catch (e) {
alert("oops! " + e.message)
}
}
// then in the child, as an example
// as stated above, even though function (args) looks like it's
// a closure in the child scope, IT IS NOT. There you go :)
var x = {blerg: 2}
functionInMainWindowContenxt = mainWindow.functionBuilder(function (args) {
// in here args is in the bound scope -- have at the child objects! :-/
function fn (blah) {
return blah * args.blerg
}
return fn
}, x)
x.blerg = 7
functionInMainWindowContext(6) // -> 42 if I did my math right
作为变体,主窗口应该能够将functionBuilder函数传递给子窗口 - 只要在主窗口上下文中定义了functionBuilder函数!
我觉得我用了太多的话。 YMMV。
答案 3 :(得分:8)
如果您尝试访问JS对象,最简单的方法是创建副本:
var objectCopy = JSON.parse(JSON.stringify(object));
希望它会有所帮助。
答案 4 :(得分:6)
这是一个非常具体的案例,我已经看到了这种行为。它在IE6和IE7中可以重现。
来自iframe:
window.parent.mySpecialHandler = function() { ...work... }
然后,在使用新内容重新加载iframe后,在包含iframe的窗口中:
window.mySpecialHandler();
此调用因“无法从释放的脚本执行代码”而失败,因为mySpecialHandler是在不再退出的上下文(iframe的原始DOM)中定义的。 (重新加载iframe会破坏此上下文。)
但是,您可以在父窗口中安全地设置“可序列化”值(基元,不直接引用函数的对象图)。如果你真的需要一个单独的窗口(在我的情况下,iframe)来为远程窗口指定一些工作,你可以将工作作为String传递并在接收器中“eval”它。小心这一点,它通常不会实现干净或安全的实施。
答案 5 :(得分:5)
当子窗口尝试与不再打开的父窗口进行通信时,MSIE中可能会发生此错误。
(不完全是世界上最有用的错误消息文本。)
答案 6 :(得分:5)
从IE9开始,当我们在另一个Object中的一个Array中存储的Date对象上调用.getTime()时,我们开始收到此错误。解决方案是在调用Date方法之前确保它是一个Date:
失败:rowTime = wl.rowData[a][12].getTime()
通过:rowTime = new Date(wl.rowData[a][12]).getTime()
答案 7 :(得分:2)
我在子框架内部遇到这个问题时我在顶层窗口中添加了一个引用类型,并在子窗口重新加载后尝试访问它
即
// set the value on first load
window.top.timestamp = new Date();
// after frame reloads, try to access the value
if(window.top.timestamp) // <--- Raises exception
...
我能够通过仅使用原始类型来解决问题
// set the value on first load
window.top.timestamp = Number(new Date());
答案 8 :(得分:1)
这不是一个真正的答案,而是更恰当的例子。
我们有框架A和框架B(这不是我的想法,但我必须忍受它)。帧A永远不会改变,帧B不断变化。我们无法将代码更改直接应用到框架A中,因此(根据供应商的说明)我们只能在框架B中运行JavaScript - 不断更改的确切框架。
我们有一段需要每5秒运行一次的JavaScript,因此框架B中的JavaScript会创建一个新的脚本标记并插入到框架B的头部.setInterval存在于这个新脚本中(注入一个),以及调用的功能。即使注入的JavaScript在技术上由帧A加载(因为它现在包含脚本标记),一旦帧B发生更改,setInterval就不再可以访问该函数。
答案 9 :(得分:0)
我在一个最终打开iFrame的页面中的IE9中出现此错误。只要iFrame没有打开,我就可以使用localStorage。打开和关闭iFrame后,由于此错误,我无法再使用localStorage。要修复它,我必须将此代码添加到iFrame内部的Javascript中,并使用localStorage。
if (window.parent) {
localStorage = window.parent.localStorage;
}
答案 10 :(得分:0)
在打开对话框时在DHTMLX中出现此错误未找到父ID或当前窗口ID
$(document).ready(function () {
if (parent.dxWindowMngr == undefined) return;
DhtmlxJS.GetCurrentWindow('wnManageConDlg').show();
});
确保在打开对话时发送正确的curr /父窗口ID
答案 11 :(得分:0)
在更新iframe&s src时,我收到了这个错误。
通过访问主窗口中的元素的事件(在我的情况下单击)得到这个错误(直接调用main / outmost窗口):
top.$("#settings").on("click",function(){
$("#settings_modal").modal("show");
});
我只是改变它,它工作正常(调用iframe窗口的父级的父级):
$('#settings', window.parent.parent.document).on("click",function(){
$("#settings_modal").modal("show");
});
我的包含模态的iframe也在另一个iframe中。
答案 12 :(得分:0)
前面的答案中的解释非常相关。只是想提供我的情况。希望这可以帮助其他人。
我们正在使用:
<script> window.document.writeln(table) </script>
,并在onchange
事件中在脚本中调用其他函数,但writeln会完全覆盖IE中的HTML,因为它在chrome中的行为不同。
我们将其更改为:
<script> window.document.body.innerHTML = table;</script>
因此保留了解决该问题的脚本。