我创建了一个IIS MVC网页。
用户发现,如果他们在一夜之间将其打开,则会在某些情况下冻结"在早上的状态,它也冻结了在浏览器中可能打开的任何其他标签。
因此,他们必须杀死整个浏览器窗口并再次登录我的网页。
如何在晚上10点干净地关闭(或处于良好状态)我的网页?
我尝试过以下版本,适用于Chrome,但不适用于Firefox:
setTimeout(function () { quitBox('quit') }, millisTill10);
function quitBox(cmd) {
if (cmd == 'quit') {
open(location, '_self').close();
window.close();
}
return false;
}
我很高兴将标签留在那里 - 但是把它放到某种干净,死的状态,不会干扰其他标签。
我试图抓住错误来修复它 - 但我不知道导致它冻结的原因。下面的代码没有抓住它:
window.onerror = function(error, url, line) {
alert('Inform please ERR:'+error+' URL:'+url+' L:'+line);
};
富勒版:
window.onerror = function (errorMsg, url, lineNumber, column, errorObj) {
var stackTrace = "Not available";
try {
stackTrace = errorObj.prototype.stack
} catch (e) {
try {
stackTrace = errorObj.stack
} catch (e) {
try {
stackTrace = errorObj.error.stack
} catch (e) {
}
}
}
alert('Please inform of Error: ' + errorMsg + ' Script: ' + url + ' Line: ' + lineNumber
+ ' Column: ' + column + ' StackTrace: ' + errorObj + ' ST: ' + stackTrace);
}
答案 0 :(得分:6)
而不是看如何杀死"选项卡,可能值得看看为什么应用程序首先死亡。 Firefox是一个单进程浏览器(目前),但它有很多安全检查来保持进程运行,这意味着有一个非常简短的事情列表,实际上可以杀死&#34 ;它
首先,让我们讨论无法杀死它的一些事情:像Java和Flash这样的插件。它们已经在一个单独的过程中运行(如果它们一直在运行): 所以最多,如果他们离家出走,他们会自杀,但浏览器的其余部分仍将继续运行。
其次,您没有看到内存警告。当JavaScript消耗太多内存时,Firefox非常适合显示错误对话框,所以如果您没有看到,那么赔率确实很高,这不是内存不足的问题。
剩下的是相当短的可能性列表:
现在让我们把它们隔开。
浏览器错误不大可能,但可能。但是,作为调试时的一般规则,假设它的您的代码已被破坏,而不是您周围的第三方框架/工具/库。有一千个非常敏锐的Mozilla开发人员每天都在努力杀死其中的任何漏洞,这意味着你看到的任何失败都可能将你的代码作为根本原因。
可能存在浏览器扩展程序/附加程序错误,但如果您在每个人的计算机上都看到这个错误,那么它们都有不同的配置并且它不是问题扩展/附加组件。不过,它可能值得在一个全新的Firefox安装中测试你的网站并让它在一夜之间进行测试;如果早上没有破坏,那么您的扩展程序/插件就会出现问题。
根据您的描述,真正的无限循环或无限递归也是不太可能的:在页面加载后很早就可以检测到这种情况;我希望在某些时候,页面会突然从完全响应变为完全死亡 - 更重要的是,浏览器有一个"无响应的脚本"如果它被卡在一个紧密的无限循环中它会显示的对话框。您没有看到"无响应脚本"对话框意味着浏览器仍在处理事件,但可能会很慢或很少处理它们,以至于它可能完全被冻结。
通常,这是"死页"的根本原因。问题:你有一些JavaScript可以很好地处理一些数据,并且可以永久地处理大量数据。
例如,您可能在页面上有代码跟踪页面的行为并将有关它的消息插入到数组中,以便最新消息位于顶部:logs.unshift(message)
该代码如果消息相对较少,则可以正常工作,当你获得几十万消息时,它会停止运行。
鉴于你的页面在半夜死亡,我会向你花钱购买甜食,你有与常规跟踪或记录相关的东西,或者可能是常规的Ajax呼叫,当它开始时,它执行一些具有整体O(n ^ 2)或O(n ^ 3)行为的动作 - 它只会变得足够慢,以便在其中包含大量数据时显而易见。
您也可以通过在DOM中意外强制重排来获得类似的行为。例如,几年前我们有一大堆JavaScript在UI中创建了一个简单的项目符号列表。插入每个项目后,它将测量项目的高度,以确定下一个项目的放置位置。它适用于十件物品 - 并且死了一百件,因为"测量高度"对于浏览器来说真的意味着,"由于有一个新项目,我们必须重新生成文档以找出所有元素大小,然后才能返回高度。"当插入第三项时,浏览器只需重新计算它之前的两个布局。但是当插入第1000个项目时,浏览器必须在它之前重新计算所有999的布局 - 这不是一个便宜的操作!
我建议您在代码中搜索此类内容,因为类似的内容可能是您的根本原因。
那么你如何找到它,特别是在大型JavaScript代码库中呢?有三种基本技术:
尝试其他浏览器
有时,使用其他浏览器会产生不同的行为。 Chrome或IE / Edge可能会中止JavaScript而不是彻底死亡,您可能会收到错误消息或JavaScript控制台消息,而不是死浏览器。如果您至少尝试过让Chrome或IE / Edge一夜之间停留在页面上,那么您可能会忽略有价值的调试消息。 (即使您的制作用户永远不会使用Chrome或IE / Edge,它至少值得测试其中的页面,看看您是否获得了可以帮助您找到错误的不同输出。)
<强>分而治之强>
让我们说你还不知道原因是什么,甚至将其他浏览器带入图片中。如果情况确实如此,那么我就可以通过&#34;分而治之的方式解决问题&#34;:
由于您的页面需要很长时间才能完成,因此这可能需要进行长时间的调试。但是分而治之的技术会找到错误,它会发现它比你想象的要快:即使你有一百万行JavaScript(而且我打赌你有远你必须在每次减半之后等待一夜,你只需要花20天的时间就可以找到完全的代码行。 (1,000,000的基数2对数约为20。)
历史分析
一个更有用的技术:如果您的源代码有版本控制(CVS,SVN,Git,Mercurial等),您可能需要考虑测试代码的旧历史副本以查看它是否具有同样的错误。 (一年前它失败了吗?六个月前?两年前?)如果你最终可以在添加错误之前的时间倒退,你可以看到导致它的实际变化是什么,你可能没有必要通过代码随意搜索它。
简而言之,虽然您可以在页面上放置一个创可贴,以使其优雅地失败 - 这可能是一个合理的短期修复,而您正在寻找实际原因 - 那里&#39;你仍然可以做很多事情来找到错误并将其修复为真实的。
我从未见过一个我无法找到并修复的错误,你也不应该放弃。
<强>附录:强>
我想在我的回答中为了完整起见,下面的简单代码可能是一个合适的&#34;杀死页面&#34;短期的创可贴。如果用户将其放置八小时,这只会使页面空白:
<script type='text/javascript'><!--
setTimeout(function() {
document.location = 'about:blank';
}, 1000 * 60 * 60 * 8); // Maximum of 8 hours, counted in milliseconds
--></script>
兼容性:这适用于使用JavaScript的每个浏览器,并且应该从90年代开始一直运行到早期版本的IE和Netscape。
但如果您完全使用此代码,请不要将其留在那里很长时间。它不是一个好主意。你应该找到 - 并修复! - 相反的错误。
答案 1 :(得分:2)
如果选项卡是由JavaScript打开的,那么您可以使用JavaScript关闭它。
如果该选项卡未被JavaScript打开,那么您可能无法使用JavaScript关闭它。
您可以配置FireFox以允许JavaScript关闭标签,方法是导航到网址栏中的about:config
并将dom.allow_scripts_to_close_windows
设置为true
。但是,这必须在逐个机器的基础上进行配置(并开启其他网站通过JavaScript关闭选项卡的可能性)。
所以:
或
PS。我还建议您查看https://developers.google.com/web/tools/chrome-devtools/memory-problems/以尝试帮助识别内存泄漏(如果应用程序有内存泄漏)或让Web应用程序每分钟ping服务器以进行日志记录(如果应用程序正在崩溃)每晚同一时间的未知时间。)
答案 2 :(得分:1)
正如其他评论中提到的,你不需要找到如何关闭,你需要如何避免“冻结”。
我建议:
收集统计信息浏览器/浏览器的内容 从浏览器中收集失败的指标,您可以使用window.performance并在超时时将日志发送到服务器(我没有尝试过,超时可以在您需要日志之前冻结)