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